--
--

SET escape_string_warning = off;


--
-- Data for Name: tm_test_description_aud; Type: TABLE DATA; Schema: public; Owner: gazelle
--

INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (1, 1, 0, '2009-11-24 10:53:15.752', 'epoiseau', 'empty description in Kudu');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (2, 1, 0, '2009-11-24 10:53:15.765', 'epoiseau', '<H3>Special Instructions</H3>  <p>This test applies to an AR sending messages to an AM. In 2009, acknowledgements are sent, but no other data is sent from an AM to an AR. </p>  <p>The test provides the steps required of the AR and the AM. They play partner roles. ARs and AMs are responsible for coordinating with their partners in advance of the Connectathon to assure that they will have the required number of systems needed for testing. It is necessary to determine that the partnering systems support the same parameters, with consistent coding. For this reason, PCD recommends (and will shortly require) that parameters be coded as defined by the Rosetta Terminology Mapping project. Consult the project manager to determine if this requirement applies. </p>  <p>This test is out of scope for the Profile. It is provided to help assure that no unexpected or significant failure will occur during the Showcase. ARs will send one alarm or alert message for one patient from this single AR. It will be sent while the AM is not available (turned off). After turning the AM on, another another message is sent to confirm the proper operation of the AR and AM. The objective is to show that the systems do not fail as a result of this transmission. </p>  <H3>Description</H3> <p>The AR sends messages as described in the test steps provided below to the AM. After confirming that the test works as intended by the developer, the message is sent again and this time the AR sends a message that the AM can receive. Messages include physiologic and/or operational parameters. The AM will note whether the initial message was sent again and received by the AM after the AM was available. </p>  <p>Parameters should be sent from actual devices (preferred), simulators or, if necessary from parameter tables provided by the Project Manager (least desirable). </p>  <u>Patient Demographics </u> <p>The AR''s patient list is developed using the rules in Kudu for test PCD_Patient_Demographics found at http://ihe-kudu.wustl.edu/na2009/connectathon_test.php.  For this test, the AR system will use any two patients from the list developed with this process. </p>  <H3>Evaluation</H3> <p>Project manager or monitor will observe the displays and/or logs provided by the sending system(s) and partner(s). The patients'' names and/or medical record numbers (MRNs), physiologic and other parameters, their measurement values, and the time of parameter t/ acquisition will be compared. The type of display/documentation by the receiving system is not constrained, it need only be clinically useful. </p>  <p>NOTE: If other tests are conducted with this test, they will be evaluated as described for those tests and the evaluation will be recorded for those tests. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (3, 1, 0, '2009-11-24 10:53:15.768', 'epoiseau', '<H3>Special Instructions</H3>  <p>This test applies to one AR sending messages to one AM and to that AM sending messages to an AC. In 2009, acknowledgements are sent, but no other data is sent from an AC to an AM or from an AM to an AR. </p>  <p>The test provides the steps required of the AR, the AM, and the AC. They play partner roles. ARs, AMs, and ACs are responsible for coordinating with their partners in advance of the Connectathon to assure that they will have the required number of systems needed for testing. It is necessary to determine that the partnering systems support the same parameters, with consistent coding. For this reason, PCD recommends (and will shortly require) that parameters be coded as defined by the Rosetta Terminology Mapping project. Consult the project manager to determine if this requirement applies. </p>  <p>ARs will send alarms and alerts for two or more patients from this single AR. If your system does not support multiple patients you need to make this known to your test partners and the project manager. </p>  <H3>Description</H3> <p>The ARs send a series of messages (as described in the test steps provided below) to the AMs. After confirming that this portion of the test works as required, the messages are sent again and this time the AM sends email messages to a Connectathon monitor. Messages include physiologic and/or operational parameters. </p>  <p>ARs send a sufficient number of messages for each of the patients specified in the test steps to document successful transmission and receipt of the data. Within the group of partners, systems should include at least two example messages for each of the system types they support (e.g., bedside monitors, infusion pumps, VSMs). Each message will contain reasonable values for at least two parameters for each system type (e.g., two or more for each patient''s monitor and two or more for each other device providing data on a patient). </p>  <p>Parameter values should be realistic for a patient in a cardiac ICU bed or on an OR table. </p>  <p>Messages for the patients will be interleaved in some manner. I.e., a sufficient number of messages is sent for each patient to see that the ARs, AMs and ACs are capable of supporting multiple patients at the same time. Messages should not be closer in time than 30 seconds apart. </p>  <p>Parameters should be sent from actual devices (preferred), simulators or, if necessary from parameter tables provided by the Project Manager (least desirable). </p>  <u>Patient Demographics </u> <p>The AR''s patient list is developed using the rules in Kudu for test PCD_Patient_Demographics found at http://ihe-kudu.wustl.edu/na2009/connectathon_test.php.  For this test, the AR system will use any two patients from the list developed with this process. </p>  <H3>Evaluation</H3> <p>Project manager or monitor will observe the displays and/or logs provided by the sending system(s) and partner(s). The patients'' names and/or medical record numbers (MRNs), physiologic and other parameters, their measurement values, and the time of parameter transmission / acquisition will be compared. The type of display/documentation by the receiving system is not constrained, it need only be clinically useful. </p>  <p>NOTE: If other tests are conducted with this test, they will be evaluated as described for those tests and the evaluation will be recorded for those tests. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (4, 1, 0, '2009-11-24 10:53:15.775', 'epoiseau', '<H3>Special Instructions</H3>  <p>This test applies to multiple ARs sending messages to at least two AMs, and it applies to AMs sending messages to one or more ACs. This test requires at least two ARs, at least two AMs, one or more ACs, two patients, and two alarms for each patient.</p>  <p>In 2009, acknowledgements are sent, but no other data is sent from an AC to an AM or from an AM to an AR. </p>  <p>The test provides the steps required of the AR, the AMs, and the AC(s). They play partner roles. ARs, AMs, and ACs are responsible for coordinating with their partners in advance of the Connectathon to assure that they will have the required number of systems needed for testing. It is necessary to determine that the partnering systems support the same parameters, with consistent coding. For this reason, PCD recommends (and will shortly require) that parameters be coded as defined by the Rosetta Terminology Mapping project. Consult the project manager to determine if this requirement applies. </p>  <p>Each AR and each AM will send alarms and alerts for two or more patients. If your system does not support multiple patients or multiple AMs or ACs you need to make this known to your test partners and to the project manager. </p>  <H3>Description</H3> <p>The ARs send a series of messages (as described in the test steps provided below) to the AMs. After confirming that this portion of the test works as required, the messages are sent again and this time the AMs send email messages to one or more Connectathon monitors or other receivers. Messages include physiologic and/or operational parameters. </p>  <p>If possible, the ARs and AMs will each be from different companies. </p>   <p>ARs send a sufficient number of messages for each of the patients specified in the test steps to document successful transmission and receipt of the data. Within the group of partners, systems should include at least two example messages for each of the system types they support (e.g., bedside monitors, infusion pumps). Each message will contain reasonable values for at least two parameters for each system type (e.g., two or more for each patient''s monitor and two or more for each other device providing data on a patient). </p>  <p>Parameter values should be realistic for a patient in a cardiac ICU bed or on an OR table. </p>  <p>Messages for the patients will be interleaved in some manner. I.e., a sufficient number of messages is sent for each patient to see that the ARs, AMs and ACs are capable of supporting multiple patients at the same time. The interval between messages is at the discretion of the systems involved. </p>  <p>Parameters should be sent from actual devices (preferred), simulators or, if necessary from parameter tables provided by the Project Manager (least desirable). </p>  <u>Patient Demographics </u> <p>The AR''s patient list is developed using the rules in Kudu for test PCD_Patient_Demographics found at http://ihe-kudu.wustl.edu/na2009/connectathon_test.php.  For this test, the AR system will use any two patients from the list developed with this process. </p>  <H3>Evaluation</H3> <p>Project manager or monitor will observe the displays and/or logs provided by the sending system(s) and partner(s). The patients'' names and/or medical record numbers (MRNs), physiologic and other parameters, their measurement values, and the time of parameter transmission / acquisition will be compared. The type of display/documentation by the receiving system is not constrained, it need only be clinically useful. </p>  <p>NOTE: If other tests are conducted with this test, they will be evaluated as described for those tests and the evaluation will be recorded for those tests. </p>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (5, 1, 0, '2009-11-24 10:53:15.785', 'epoiseau', '<H3>Special Instructions</H3>  <p>This test applies to an AR sending messages to an AM. In 2009, acknowledgements are sent, but no other data is sent from an AM to an AR. </p>  <p>The test provides the steps required of the AR and the AM. They play partner roles. ARs and AMs are responsible for coordinating with their partners in advance of the Connectathon to assure that they will have the required number of systems needed for testing. It is necessary to determine that the partnering systems support the same parameters, with consistent coding. For this reason, PCD recommends (and will shortly require) that parameters be coded as defined by the Rosetta Terminology Mapping project. Consult the project manager to determine if this requirement applies. </p>  <p>This test is out of scope for the Profile. It is provided to help assure that no unexpected or significant failure will occur during the Showcase. ARs will send one alarm or alert message for one patient from this single AR. It will contain data that the AM is not prepared to accept. That message is followed by an acceptable transmission. The objective is to show that the systems do not fail as a result of this transmission. </p>  <H3>Description</H3> <p>The AR sends messages as described in the test steps provided below to the AM. After confirming that this portion of the test works as intended by the developer, the message is sent again and this time the AR sends a message that the AR and AM can both support. Messages include physiologic and/or operational parameters. </p>  <p>Parameters should be sent from actual devices (preferred), simulators or, if necessary from parameter tables provided by the Project Manager (least desirable). </p>  <u>Patient Demographics </u> <p>The AR''s patient list is developed using the rules in Kudu for test PCD_Patient_Demographics found at http://ihe-kudu.wustl.edu/na2009/connectathon_test.php.  For this test, the AR system will use any two patients from the list developed with this process. </p>  <H3>Evaluation</H3> <p>Project manager or monitor will observe the displays and/or logs provided by the sending system(s) and partner(s). The patients'' names and/or medical record numbers (MRNs), physiologic and other parameters, their measurement values, and the time of parameter t/ acquisition will be compared. The type of display/documentation by the receiving system is not constrained, it need only be clinically useful. </p>  <p>NOTE: If other tests are conducted with this test, they will be evaluated as described for those tests and the evaluation will be recorded for those tests. </p>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (6, 1, 0, '2009-11-24 10:53:15.801', 'epoiseau', '<H3>Special Instructions</H3><p></p><H3>Description</H3><p>ADT system broadcasts ADT messages to DSS/Order Fillers (only). Observer will ask DSS/Order Fillers to show results of ADT messages.</p><H3>Evaluation</H3><p>On the <strong>DSS/Order Filler</strong> user interface or database, verify:</p><ul> <li>Patient COMPANY^George is an inpatient (his name was changed from COMPANY^Monday).</li> <li>Patient COMPANY^Tuesday was merged with patient Doe^Company</li> </ul><p>To be verified in ADT messages:</p><ul> <li>A01, A04, A05, A11, A38: At least one of the fields PID-18 Patient Account Number or PV1-19 Visit Number shall be valued</li> <li>A01: PV1-3 PV1-7 PV1-10 PV1-17 shall be valued</li> <li>A04, A05, A11, A38: PV1-3 PV1-7 PV1-10 PV1-17 shall not be valued</li> <li>ADT^A40 shows both ''^Tuesday'' and ''^Doe'' patient names</li> </ul><p>Project manager may ask you to give names with titles, prefix, suffix and or aliases. For Example:</p><ul> <li>Jean-Baptiste Poquelin, alias Moli&egrave;re</li>  <li>Clark Kent alias Superman</li> <li>Johann Wolfgang von Goethe alias Goethe</li> <li>Martin Luther King, Jr</li> <li>Michaelangelo Buonarroti alias Michelangelo</li> <li>Silvio Berlusconi alias il Cavaliere</li> <li>Dr Jack Rabbit</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (7, 1, 0, '2009-11-24 10:53:15.84', 'epoiseau', '<H3>Special Instructions</H3> None. <H3>Description</H3> <p> ADT system broadcasts ADT messages to Order Placers (only). Observer will ask Order Placers to show results of ADT messages </p> <H3>Evaluation</H3> <p> On the <strong>Order Placer</strong> user interface or database, verify: </p> <ul> <li>Patient COMPANY^George is an inpatient (his name was changed from COMPANY^Monday). <li>Patient COMPANY^Tuesday  was merged with patient Doe^COMPANY. </ul> <p>To be verified in ADT messages : </p> <ul> <li>A01, A04, A05, A11, A38 : At least one of the fields PID-18 Patient Account Number or PV1-19 Visit Number shall be valued. <li>A01 :  PV1-3 PV1-7  PV1-10 PV1-17 shall be valued</li> <li>A04, A05, A11, A38 : PV1-3 PV1-7  PV1-10 PV1-17 shall not be valued</li> <li>ADT^A40 shows both ''^Tuesday'' and ''^Doe'' patient names  </ul>  </p>  <p>Project manager may ask you to give names with titles, prefix, suffix and or aliases :  For example <ul> <li>Jean-Baptiste Poquelin, alias Moli''re </li> <li>Clark Kent alias Superman</li> <li>Johann Wolfgang von Goethe alias Goethe</li> <li>Martin Luther King, Jr</li> <li>Michelangelo Buonarroti alias Michelangelo</li> <li>Silvio Berlusconi alias il Cavaliere</li> <li>Dr Jack Rabbit</li> </ul></p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (8, 1, 0, '2009-11-24 10:53:15.892', 'epoiseau', '<H3>Special Instructions</H3> None. <H3>Description</H3> <p> ADT system broadcasts ADT messages to Order Placers (only). Observer will ask Order Placers to show results of ADT messages </p> <H3>Evaluation</H3> <p> On the <strong>Order Placer</strong> user interface or database, verify: </p> <ul> <li>Patient COMPANY^George is an inpatient (his name was changed from COMPANY^Monday). <li>Patient COMPANY^Tuesday  was merged with patient Doe^COMPANY. </ul> <p>To be verified in ADT messages : </p> <ul> <li>A01, A04, A05, A11, A38 : At least one of the fields PID-18 Patient Account Number or PV1-19 Visit Number shall be valued. <li>A01 :  PV1-3 PV1-7  PV1-10 PV1-17 shall be valued</li> <li>A04, A05, A11, A38 : PV1-3 PV1-7  PV1-10 PV1-17 shall not be valued</li> <li>ADT^A40 shows both ''^Tuesday'' and ''^Doe'' patient names  </ul>  </p>  <p>Project manager may ask you to give names with titles, prefix, suffix and or aliases :  For example <ul> <li>Jean-Baptiste Poquelin, alias Moli''re </li> <li>Clark Kent alias Superman</li> <li>Johann Wolfgang von Goethe alias Goethe</li> <li>Martin Luther King, Jr</li> <li>Michelangelo Buonarroti alias Michelangelo</li> <li>Silvio Berlusconi alias il Cavaliere</li> <li>Dr Jack Rabbit</li> </ul></p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (9, 1, 0, '2009-11-24 10:53:15.895', 'epoiseau', '<H3>Special Instructions</H3><p> <p>None</p> </p><H3>Description</H3><p>ADT system broadcasts ADT messages to Order Result Tracker (only). Observer will ask Order Result Tracker to show results of ADT messages</p><H3>Evaluation</H3><p>To be verified in ADT messages:</p><ul> <li>A01, A04, A05, A11, A38 : At least one of the fields PID-18 Patient Account Number or PV1-19 Visit Number shall be valued.</li> <li>A01 : PV1-3 PV1-7 PV1-10 PV1-17 shall be valued</li> <li>A04, A05, A11, A38 : PV1-3 PV1-7 PV1-10 PV1-17 shall not be valued</li> </ul><p>Project manager may ask you to give names with titles, prefix, suffix and or aliases : For example</p><ul> <li>Jean-Baptiste Poquelin, alias Moli''re</li> <li>Clark Kent alias Superman</li> <li>Johann Wolfgang von Goethe alias Goethe</li> <li>Georg Bush, Jr</li> <li>Michelangelo Buonarroti alias Michelangelo</li> <li>Silvio Berlusconi alias il Cavaliere</li> <li>Dr Jack Rabbit</li> </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (10, 1, 0, '2009-11-24 10:53:15.902', 'epoiseau', '<H3>Special Instructions</H3> <p>Complete this test as a Creator or Consumer if you create/consume APR Antepartum Education Documents </p> <p>Content Consumers please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find the sample document(s) your peers have submitted. </p>  <H3>Description</H3> <p>There are four processing options defined for the Content  Consumer:</p><ul> <li>View</li> <li>Document Import</li> <li>Section Import</li> <li>Discrete Data Import</li> </ul> <p>In this test, the Content Consumer locates the Antepartum Education 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 APR 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 (11, 1, 0, '2009-11-24 10:53:15.904', 'epoiseau', 'empty description in Kudu');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (12, 1, 0, '2009-11-24 10:53:15.91', 'epoiseau', '<H3>Special Instructions</H3> <p>Complete this test as a Creator or Consumer if you create/consume APR Health and Physical Documents </p> <p>Content Consumers please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find the sample document(s) your peers have submitted. </p>  <H3>Description</H3> <p>There are four processing options defined for the Content  Consumer:</p><ul> <li>View</li> <li>Document Import</li> <li>Section Import</li> <li>Discrete Data Import</li> </ul> <p>In this test, the Content Consumer locates the Health and Physical 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 APR 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 (13, 1, 0, '2009-11-24 10:53:15.914', 'epoiseau', '<H3>Special Instructions</H3> <p>Complete this test as a Creator or Consumer if you create/consume APR Antepartum Summary Documents </p> <p>Content Consumers please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find the sample document(s) your peers have submitted. </p>  <H3>Description</H3> <p>There are four processing options defined for the Content  Consumer:</p><ul> <li>View</li> <li>Document Import</li> <li>Section Import</li> <li>Discrete Data Import</li> </ul> <p>In this test, the Content Consumer locates the Antepartum Summary 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 APR 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 (14, 1, 0, '2009-11-24 10:53:15.916', '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 Antepartum Education 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 Antepartum Education document. We recognize that not all renderings will be the same.</li> <li>Name the document APS_kudu.xml where <strong><em>kudu</em></strong> is your Kudu system name.</li> <li>Upload information, snapshot and xml files in the <em>Connectathon Images/CDAs/Objects</em> section of Kudu.</li> <li> Upload your 2 documents according to the instructions on that  page. Update the <em> Connectathon Images/CDAs/Objects Publication/rendering page</em> page to list your document/zip file.</li> <li>Find the Connectathon monitor or monitors responsible for Document Scrutiny. Make sure they are aware your document has been placed into the Kudu tool.</li> <li>If you support XDS, complete XDS test that requires you to store and register your document with a repository/registry. You do not need to complete that XDS store step in order to complete this test. In fact, once you have uploaded the proper documentation into Kudu, mark this test complete.</li> </ol><p>These items describe the minimum content that must be  present in the APS document. Additional content is acceptable, but the  document must contain the following information:</p><p>The content of various modules is defined at http://ihewiki.wustl.edu/wiki/index.php/PCC_Connectathon_Content_Test_Requirements. Use the wiki page to find the right content and incorporate into your document.</p><p>As defined in the PCC TF, you must include the following content modules. Optional modules are allowed.  <table>  <tr><th>Module</th><th>Template ID</th></tr>  <tr><td>Coded Patient Education and Consents</td><td>1.3.6.1.4.1.19376.1.5.3.1.1.9.39</td></tr> </table> </p> <H3>Evaluation</H3> <p>This will be evaluated with the APR_Scrutiny_Education and APS_Process_Education tests.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (15, 1, 0, '2009-11-24 10:53:15.918', '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 Antepartum History and Physical 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 Antepartum History and Physical document. We recognize that not all renderings will be the same.</li> <li>Name the document APR_HP_kudu.xml where <strong><em>kudu</em></strong> is your Kudu system name.</li> <li>Upload information, snapshot and xml files in the <em>Connectathon Images/CDAs/Objects</em> section of Kudu.</li> <li> Upload your 2 documents according to the instructions on that  page. Update the <em>Connectathon Images/CDAs/Objects Publication/rendering page</em> page to list your document/zip file.</li> <li>Find the Connectathon monitor or monitors responsible for Document Scrutiny. Make sure they are aware your document has been placed into the Kudu tool.</li> <li>If you support XDS, complete XDS test that requires you to store and register your document with a repository/registry. You do not need to complete that XDS store step in order to complete this test. In fact, once you have uploaded the proper documentation into Kudu, mark this test complete.</li> </ol><p>These items describe the minimum content that must be  present in the APS document. Additional content is acceptable, but the  document must contain the following information:</p><p>The content of various modules is defined at http://ihewiki.wustl.edu/wiki/index.php/PCC_Connectathon_Content_Test_Requirements. Use the wiki page to find the right content and incorporate into your document.</p> <p>As defined in the PCC TF, you must include the following content modules. Optional modules are allowed. <table> <tr><th>Module</th><th>Template ID</th></tr> <tr><td>Chief Complaint</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.1</td></tr> <tr><td>History of Present Illness</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.4</td></tr> <tr><td>History of Past Illness</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.8</td></tr> <tr><td>Medications</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.19</td></tr> <tr><td>Allergies and Other Adverse Reactions</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.13</td></tr> <tr><td>Social History</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.16</td></tr> <tr><td>Family History</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.14</td></tr> <tr><td>Review of Systems</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.18</td></tr> <tr><td>Physical Examination</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.9.15</td></tr> <tr><td>Vital Signs</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.25</td></tr> <tr><td>Results</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.27</td></tr> <tr><td>Coded Results</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.28</td></tr> <tr><td>Assessment and Plan</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.5</td></tr> </table>  </p><H3>Evaluation</H3><p>This will be evaluated with the APR_Scrutiny_History_Physical and APR_Process_History_Physical tests.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (16, 1, 0, '2009-11-24 10:53:15.92', 'epoiseau', 'empty description in Kudu');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (17, 1, 0, '2009-11-24 10:53:15.922', '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 Antepartum Summary 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 Antepartum Summary document. We recognize that not all renderings will be the same.</li> <li>Name the document APR_Summary_kudu.xml where <strong><em>kudu</em></strong> is your Kudu system name.</li> <li>Upload information, snapshot and xml files in the <em>Connectathon Images/CDAs/Objects</em> section of Kudu.</li> <li> Upload your 2 documents according to the instructions on that  page. Update the <em>Connectathon Images/CDAs/Objects Publication/rendering page</em> page to list your document/zip file.</li> <li>Find the Connectathon monitor or monitors responsible for Document Scrutiny. Make sure they are aware your document has been placed into the Kudu tool.</li> <li>If you support XDS, complete XDS test that requires you to store and register your document with a repository/registry. You do not need to complete that XDS store step in order to complete this test. In fact, once you have uploaded the proper documentation into Kudu, mark this test complete.</li> </ol> <p>These items describe the minimum content that must be  present in the APS document. Additional content is acceptable, but the  document must contain the following information:</p><p>The content of various modules is defined at http://ihewiki.wustl.edu/wiki/index.php/PCC_Connectathon_Content_Test_Requirements. Use the wiki page to find the right content and incorporate into your document.</p> <p>As defined in the PCC TF, you must include the following content modules. Optional modules are allowed. <table>  <tr><th>Module</th><th>Template ID</th></tr>  <tr><td>Allergies</td><td>1.3.6.1.4.1.19376.1.5.3.1.3.13</td></tr>  <tr><td> Advance Directives</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.34</td></tr>  <tr><td> Plan of Care</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.31</td></tr>  <tr><td> Medications</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.19</td></tr>  <tr><td> Problems</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.6</td></tr>  <tr><td> Estimated Delivery Dates</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.11.2.2.1</td></tr>  <tr><td> Antepartum Visit Summary Flowsheet</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.11.2.2.2</td></tr> </table>  </p><H3>Evaluation</H3><p>This will be evaluated with the APR_Scrutiny_History_Physical and APR_Process_History_Physical tests.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (18, 1, 0, '2009-11-24 10:53:15.925', '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 APR documents.      The purpose of this test is to have a single person with domain knowledge examine one      example of each document.      The Connectathon Monitor is looking for proper document structure, proper use of coded values      and content that was specified in the Publish test.</p> <p>The Content Creator should use the same documents produced and stored in the Kudu tool in the APR_Publish_Education test.</p> <p>The Connectathon Monitor will take the files offline and perform evaluation.      The monitor will document any deficiencies and ask the Content Creator to correct      during the Connectathon.</p>  <H3>Evaluation</H3> <p>Monitors please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find the sample document(s) the Content Creators have submitted. </p>  <p>The NIST Evaluation tools are found at <a href="http://xreg2.nist.gov/cda-validation/index.html">http://xreg2.nist.gov/cda-validation/index.html</a> .      For documents not supported by the NIST tool, use the schematron file found at IHESCHEMATRON.   </p><p>In the evaluation, the Connectathon Monitor will follow these steps:    <ol>      <li>Use CDA validation tool to make sure document is legal CDA document</li>      <li>Use Schematron test tool to see that document passes schematron tests for APR Education Summary</li>      <li>Examine APR Education document by hand (possibly with style sheet) and examine for APR 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>Coded Patient Education and Consents</td><td>1.3.6.1.4.1.19376.1.5.3.1.1.9.39</td></tr> </table>   </li>     </ol> </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (19, 1, 0, '2009-11-24 10:53:15.927', '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 APR documents.      The purpose of this test is to have a single person with domain knowledge examine one      example of each document.      The Connectathon Monitor is looking for proper document structure, proper use of coded values      and content that was specified in the Publish test.</p><p>The Content Creator should use the same documents produced and stored in the Kudu tool in the APR_Publish_HP test.</p><p>The Connectathon Monitor will take the files offline and perform evaluation.      The monitor will document any deficiencies and ask the Content Creator to correct      during the Connectathon.</p>  <H3>Evaluation</H3> <p>Monitors please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find the sample document(s) the Content Creators  have submitted. </p>  <p>The NIST Evaluation tools are found at <a href="http://xreg2.nist.gov/cda-validation/index.html">http://xreg2.nist.gov/cda-validation/index.html</a> .      For documents not supported by the NIST tool, use the schematron file found at IHESCHEMATRON.   </p><p>In the evaluation, the Connectathon Monitor will follow these steps:    <ol>      <li>Use CDA validation tool to make sure document is legal CDA document</li>      <li>Use Schematron test tool to see that document passes schematron tests for APR Health and Physical</li>      <li>Examine APR Health and Physical by hand (possibly with style sheet) and examine for APR 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>Chief Complaint</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.1</td></tr> <tr><td>History of Present Illness</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.4</td></tr> <tr><td>History of Past Illness</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.8</td></tr> <tr><td>Medications</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.19</td></tr> <tr><td>Allergies and Other Adverse Reactions</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.13</td></tr> <tr><td>Social History</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.16</td></tr> <tr><td>Family History</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.14</td></tr> <tr><td>Review of Systems</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.18</td></tr> <tr><td>Physical Examination</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.9.15</td></tr> <tr><td>Vital Signs</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.25</td></tr> <tr><td>Results</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.27</td></tr> <tr><td>Coded Results</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.28</td></tr> <tr><td>Assessment and Plan</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.5</td></tr> </table>  </li>     </ol> </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (20, 1, 0, '2009-11-24 10:53:15.93', 'epoiseau', 'empty description in Kudu');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (21, 1, 0, '2009-11-24 10:53:15.932', '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 APR documents.      The purpose of this test is to have a single person with domain knowledge examine one      example of each document.      The Connectathon Monitor is looking for proper document structure, proper use of coded values      and content that was specified in the Publish test.</p><p>The Content Creator should use the same documents produced and stored in the Kudu tool in the APR_Publish_Summary test.</p><p>The Connectathon Monitor will take the files offline and perform evaluation.      The monitor will document any deficiencies and ask the Content Creator to correct      during the Connectathon.</p>  <H3>Evaluation</H3> <p>Monitors please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find the sample document(s) the Content Creators  have submitted. </p>  <p>The NIST Evaluation tools are found at <a href="http://xreg2.nist.gov/cda-validation/index.html">http://xreg2.nist.gov/cda-validation/index.html</a> .      For documents not supported by the NIST tool, use the schematron file found at IHESCHEMATRON.   </p><p>In the evaluation, the Connectathon Monitor will follow these steps:    <ol>      <li>Use CDA validation tool to make sure document is legal CDA document</li>      <li>Use Schematron test tool to see that document passes schematron tests for APR Antepartum Summary</li>      <li>Examine APR Antepartum Summary by hand (possibly with style sheet) and examine for APR 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>Allergies</td><td>1.3.6.1.4.1.19376.1.5.3.1.3.13</td></tr>  <tr><td> Advance Directives</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.34</td></tr>  <tr><td> Plan of Care</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.31</td></tr>  <tr><td> Medications</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.19</td></tr>  <tr><td> Problems</td><td> 1.3.6.1.4.1.19376.1.5.3.1.3.6</td></tr>  <tr><td> Estimated Delivery Dates</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.11.2.2.1</td></tr>  <tr><td> Antepartum Visit Summary Flowsheet</td><td> 1.3.6.1.4.1.19376.1.5.3.1.1.11.2.2.2</td></tr> </table>   </li>     </ol> </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (22, 1, 0, '2009-11-24 10:53:15.936', '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 Antepartum Summary 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 APS 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 (23, 1, 0, '2009-11-24 10:53:15.937', '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 Antepartum Summary 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 Antepartum Summary document. We recognize that not all renderings will be the same.</li> <li>Name the document APS_kudu.xml where <strong><em>kudu</em></strong> is your Kudu system name.</li> <li>Upload information, snapshot and xml files in the <em>Connectathon Images/CDAs/Objects</em> section of Kudu.</li> <li> Upload your 2 documents according to the instructions on that  page. Update the <em> Connectathon Images/CDAs/Objects Publication/rendering page</em> page to list your document/zip file.</li> <li>Find the Connectathon monitor or monitors responsible for Document Scrutiny. Make sure they are aware your document has been placed into the Kudu tool.</li> <li>If you support XDS, complete XDS test that requires you to store and register your document with a repository/registry. You do not need to complete that XDS store step in order to complete this test. In fact, once you have uploaded the proper documentation into Kudu, mark this test complete.</li> </ol><p>These items describe the minimum content that must be  present in the APS 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.  <ol> <li>Allergies, 1.3.6.1.4.1.19376.1.5.3.1.3.13</li> <li>Advance Directives, 1.3.6.1.4.1.19376.1.5.3.1.3.34</li> <li>Plan of Care, 1.3.6.1.4.1.19376.1.5.3.1.3.31</li> <li>Medications, 1.3.6.1.4.1.19376.1.5.3.1.3.19</li> <li>Problems, 1.3.6.1.4.1.19376.1.5.3.1.3.6</li> <li>Estimated Delivery Dates, 1.3.6.1.4.1.19376.1.5.3.1.1.11.2.2.1</li> <li>Antepartum Visit Summary Flowsheet, 1.3.6.1.4.1.19376.1.5.3.1.1.11.2.2.2</li> </ol> </p><H3>Evaluation</H3><p>This will be evaluated with the APS_Scrutiny and APS_Process tests.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (24, 1, 0, '2009-11-24 10:53:15.941', '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 APS 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 APS_Publish 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 http://xreg2.nist.gov/cda-validation/index.html.      For documents not supported by the NIST tool, use the schematron file found at IHESCHEMATRON.   </p><p>In the evaluation, the Connectathon Monitor will follow these steps:    <ol>      <li>Use CDA validation tool to make sure document is legal CDA document</li>      <li>Use Schematron test tool to see that document passes schematron tests for APS</li>      <li>Examine APS by hand (possibly with style sheet) and examine for APS 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:      <ol>        <li>Allergies, 1.3.6.1.4.1.19376.1.5.3.1.3.13</li>        <li>Advance Directives, 1.3.6.1.4.1.19376.1.5.3.1.3.34</li>        <li>Plan of Care, 1.3.6.1.4.1.19376.1.5.3.1.3.31</li>        <li>Medications, 1.3.6.1.4.1.19376.1.5.3.1.3.19</li>        <li>Problems, 1.3.6.1.4.1.19376.1.5.3.1.3.6</li>        <li>Estimated Delivery Dates, 1.3.6.1.4.1.19376.1.5.3.1.1.11.2.2.1</li>        <li>Antepartum Visit Summary Flowsheet, 1.3.6.1.4.1.19376.1.5.3.1.1.11.2.2.2</li>       </ol>      </li>     </ol> </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (25, 1, 0, '2009-11-24 10:53:15.943', 'epoiseau', '<H3>Special Instructions</H3> <p>Try to be efficient while performing this test. Indeed as an ID you may also want to get the <b>CPI_C_SOFT</b> or <b>CPI_M_SOFT</b> test validated at the same time. </p> <p> If the Image Display and Image Manager/Image Archive actors support the content profile Consistent Presentation of Images (CPI), they must successfully complete this test to receive credit for ARI. </p> <p>Test <b>CPI_Archive </b>(in the CPI Connectathon Tests) must be completed first. </p> <H3>Description</H3> <p>Image Display should query Image Manager for GSPS objects and images. Images/GSPS objects should be retrieved and rendered appropriately.</p>  <P>The Q/R of the GSPS object is required if the CPI Profile is supported by the Image Display actor.</p>  <p>Testing of the rendering is performed in the test <b>CPI_C_SOFT</b>. </p>  <h3>Evaluation</h3> <p>For evaluation, the Project Manager should make sure that the Image Display can query the Image Manager and return results. Retrieving the GSPS objects and images will ensure that the Image Manager faithfully reproduces the data that it stores.</p> <p><strong>This test provides equivalence for test ARI_IMG </strong></p> <p></p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (26, 1, 0, '2009-11-24 10:53:15.948', 'epoiseau', '<H3>Special Instructions</H3> <font color=red>DO NOT DO THIS TEST IS YOU ALREADY HAVE DONE ARI_GSPS WITH THE SAME PARTNER</font><br>  The Image Manager/Archive must complete a Modality-Image Manager test before this test can be run with the Image Display actor.  This ensures images are already available on the IM. <p>This test is used in the ARI , NMI and SWF profiles; it tests the required query/retrieve transactions between and ID and IM actor.   </p> <p>This test can be replaced by ARI_GSPS for Image Displays that support GSPS objects.</p> <H3>Description</H3> <p> Image Display should query Image Manager for images. Image Display should demonstrate query keys as listed in TF.</p>  <p>Images should be retrieved and displayed. </p>  <H3>Evaluation</H3> <p><i> Evaluators and participants should note that this section contains all query keys documented in the Technical Framework.  At the North American Connectathon in Chicago, many Display vendors were surprised that these are requirements.  We are *not* failing systems this year if you do not support everything below.  However, the Connectathon Monitor will verify that you have a reasonable implementation that allows you to query the Image Manager using different parameters. </i></p>  On the <b>Image Display </b> <ul> <li>The Connectathon Monitor will ask the operator to demonstrate its support for the DICOM Study Root Q/R Information Model and Hierarchical Search. <p>It will demonstrate on its User Interface the ability to offer its user the following attributes as selection criteria (ie  these required query keys for the Image Displays SCU (RAD TF-2 Table 4.14-1). Query the Image Manager for combinations of: <p> <p><b>STUDY LEVEL</b> Query Keys:</p> <ul> <li>Study Date (0008,0020) <li>Study Time (0008,0030) <li>Accession Number (0008,0050)  <li>Patient Name (0010,0010) <li>Study ID (0020,0010)  <li>Study Instance UID (0020,000D) <li>Modalities in Study (0008,0061) <li>Referring Physician''s Name (0008,0090) </ul> <p><b>SERIES LEVEL</b> Query Keys: <ul> <li>Modality (0008,0020) <li>Series Number (0020,0011)  <li>Series Instance UID (0020,000E) <li>Requested Procedure ID (0040,1001)  <li>Scheduled Procedure Step ID (0040,0009)   <li>PPS Start Date (0040,0244)  <li>PPS Start Time (0040,0245) </ul> <p><b>IMAGE LEVEL </b>Query Keys:</p> <ul> <li>Instance Number (0020,0013)  <li>SOP Instance UID (0008,0016) </ul> <p> </p> <li>Verify the ability to retrieve by study, by series and by image.  Images should be retrieved and displayed. GSPS objects should be displayed if supported.   <p>For evaluation, the Project Manager should make sure that the Image Display can query the Image Manager and return results. Retrieving the images will ensure that the Image Manager faithfully reproduces the data that it stores. (Detailed rendering evaluation is done in the Display tests in the Content profiles.) </p> </ul>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (27, 1, 0, '2009-11-24 10:53:15.953', 'epoiseau', '<H3>Special Instructions</H3><p> <strong>DO NOT DO THIS TEST IS YOU ALREADY HAVE DONE ARI_GSPS WITH THE SAME PARTNER</strong> <p>The Image Manager/Archive must complete a Modality-Image Manager test before this test can be run with the Image Display actor. This ensures images are already available on the IM.</p> <p>This test is used in the ARI , NMI and SWF profiles; it tests the required query/retrieve transactions between and ID and IM actor.</p> <p>This test can be replaced by ARI_GSPS for Image Displays that support GSPS objects.</p> </p> <H3>Description</H3> <p>Here we test the ARI Option Multiple Sources. Do not run the test if you do not support that option</p> <p>In order to claim support for this profile option, an Image Display shall be able to query and retrieve from multiple Image Manager/Image Archives.</p> <p>There is no requirement as to whether the multiple queries or retrieves are done concurrently or sequentially.</p> <p>Image Displays shall have the ability to be configured to access multiple Image Manager/Image Archives (respectively).</p> <p>Image Managers shall also support the Patient Information Reconciliation integration profile in order to ensure that the information gathered from them is as accurate as possible. Since having actors in different ADT (patient identifier) domains could result in unpredictable query results, this option assumes that all actors are members of the same ADT domain (i.e., it can be assumed that a given patient identifier uniquely refers to a single patient).</p> <p>An Image Display supporting this profile option may be configured to initially query only its local information source; however, it shall be possible to query multiple sources with a single user request.</p> <p>When an Image Display and Report Reader are combined, a single user request shall suffice to trigger a query of multiple sources for both images (and anything else stored in an Image Manager/Image Archive) and reports.</p> <p>If communication with an information source fails, an Image Display shall provide the information it received from the other sources. In addition, the Image Display shall inform the user that they are viewing potentially incomplete results.</p> <p>When an Image Display performs a study-level or series-level query to multiple sources and finds the study/series referenced in multiple places, the study/series is either duplicated or the study/series is split across the systems. When the user requests a retrieval of the study/series an Image Display shall collate the information, determine if the information is actually duplicated or split, and present to the user a consolidated view of results. The consolidated view of results may be shown and updated either as responses are received or when the final response has been received from the last responding information source.</p> <p>A participating Image Display shall manage duplicate instances in a manner that avoids redundant retrieve.</p>  <H3>Evaluation</H3> <p> <em>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.</em> </p> <p>On the <strong>Image Display:</strong> </p> <ul> <li>The Connectathon Monitor will ask the operator to demonstrate its support for the DICOM Study Root Q/R Information Model and Hierarchical Search.</li> <li>It will demonstrate on its User Interface the ability to offer its user the following attributes as selection criteria (ie these required query keys for the Image Displays SCU (RAD TF-2 Table 4.14-1). Query the Image Manager for combinations of:</li>  <li> <strong>STUDY LEVEL</strong> Query Keys:     <ul> 	   <li>Study Date (0008,0020)</li>         <li>Study Time (0008,0030) </li>        <li>Accession Number (0008,0050)</li>         <li>Patient Name (0010,0010) </li>        <li>Study ID (0020,0010) </li>        <li>Study Instance UID (0020,000D)</li>         <li>Modalities in Study (0008,0061) </li>        <li>Referring Physician’s Name (0008,0090)</li> 	 </ul> </li> <li> <strong>SERIES LEVEL</strong> Query Keys:     <ul> 	   <li>Modality (0008,0020)</li>         <li>Series Number (0020,0011) </li>        <li>Series Instance UID (0020,000E) </li>        <li>Requested Procedure ID (0040,1001) </li>        <li>Scheduled Procedure Step ID (0040,0009)</li>         <li>PPS Start Date (0040,0244)</li>         <li>PPS Start Time (0040,0245)</li>  	 </ul> </li> <li> <strong>IMAGE LEVEL</strong> Query Keys:     <ul> 	   <li>Instance Number (0020,0013)</li>        <li>SOP Instance UID (0008,0016)</li> 	 </ul> </li> </ul><p>Verify the ability to retrieve by study, by series and by image. Images should be retrieved and displayed. GSPS objects should be displayed if supported. For evaluation, the Project Manager should make sure that the Image Display can query the Image Manager and return results. Retrieving the images will ensure that the Image Manager faithfully reproduces the data that it stores. (Detailed rendering evaluation is done in the Display tests in the Content profiles.)</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (28, 1, 0, '2009-11-24 10:53:15.956', 'epoiseau', '<H3>Special Instructions</H3><p> <p>There is the need for at least 3 partners for this test. Thus is this strongly suggested to use the central archive as one of the sources.</p> <p> Here we test the ARI Option Multiple Sources. Do not run the test if you do not support that option.</p> </p><H3>Description</H3><p>In order to claim support for this profile option, an Report Reader shall be able to query and retrieve from multiple Report Repositories.</p><p>There is no requirement as to whether the multiple queries or retrieves are done concurrently or sequentially.</p><p>Report Readers  shall have the ability to be configured to access multiple Report Repositories  (respectively).</p><p> Report Repositories shall also support the Patient Information Reconciliation integration profile in order to ensure that the information gathered from them is as accurate as possible.    Since having actors in different ADT (patient identifier) domains could result in unpredictable query results, this option assumes that all actors are members of the same ADT domain (i.e., it can be assumed that a given patient identifier uniquely refers to a single patient).</p><p>A Report Reader  supporting this profile option may be configured to initially query only its local information source; however, it shall be possible to query multiple sources with a single user request.</p><H3>Evaluation</H3><p>When an Image Display and Report Reader are combined, a single user request shall suffice to trigger a query of multiple sources for both images (and anything else stored in an Image Manager/Image Archive) and reports.</p><p>    If communication with an information source fails, an Image Display shall provide the information it received from the other sources. In addition, the Image Display  shall inform the user that they are viewing potentially incomplete results.   </p><p>When an Image Display  performs a study-level or series-level query to multiple sources and finds the study/series referenced in multiple places, the study/series is either duplicated or the study/series is split across the systems. When the user requests a retrieval of the study/series an Image Display  shall collate the information, determine if the information is actually duplicated or split, and present to the user a consolidated view of results.     The consolidated view of results may be shown and updated either as responses are received or when the final response has been received from the last responding information source.</p><p>A participating Image Display  shall manage duplicate instances in a manner that avoids redundant retrieval.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (29, 1, 0, '2009-11-24 10:53:15.958', 'epoiseau', '<H3>Special Instructions</H3> This test requires 2 datasets for the same patient - dataset A & B.  A & B can be 2 different imaging studies for the same patient or 2 different reports (SRs).  Alternatively, A can be images and B can be SRs. <ul> <li>The Image Manager or Report Repository should store dataset A <li>The Central Archive should store dataset A (a duplicate) and also dataset B. </ul> <H3>Description</H3> Here we test the ARI Multiple Sources Option. Do not run the test if you do not support that option. <p>Image Display/Report Reader should query different Image Manager/Report Repositories and/or Central Archive for studies for a specific patient. Image Display/Report Reader should demonstrate a unified list of studies in GUI. </p> <H3>Evaluation</H3> On the <b>Image Display / Report Reader</b>, the Connectathon Monitor will observe: <ul> <li>a <b>single user request</b> triggers a query to mutiple sources <li>a unified list of studies is presented on the GUI <li>duplicated studies (dataset A) appear only once </ul> <p><b>If the Image Display and Report Repository actors are combined in one system</b>, the Connectathon Monitor will verify: <ul> <li>a <b>single user request </b>triggers a query of multiple sources for both images and reports. <li>the returned results of the query are presented to the user in a consolidated view. </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (30, 1, 0, '2009-11-24 10:53:15.961', 'epoiseau', '<H3>Special Instructions</H3> If the Image Display and Image Manager have completed any of the ED_Modality_PACS_Display* tests, in the radiology Evidence Document Connectathon Tests, they do not need to run this test <H3>Description</H3> This tests the interface between a Report Reader and Report Repository for the query and retrieve of SR objecects <H3>Evaluation</H3> Report Reader should query Report Repository for SR objects. Report Reader should demonstrate query keys as listed in TF. <p> SR objects should be retrieved and rendered. If reports contain references to images, images should be retrieved and displayed (if supported). </p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (31, 1, 0, '2009-11-24 10:53:15.962', 'epoiseau', '<p>ATNAMultipleEvents tracks one user through a system performing multiple actions. These are a login failure, successful login and access to a patient record of some kind. At least 3 audit records should be generated and sent to the Audit Repository.</p>  <p>For the failure event, the user should try to login using a name that is easily identifiable with your company/product. For example, himssxx would indicate the wrong login name for HIMSS. For the successful login, select a user name that is also easily identifiable with your company/product (e.g., himss).</p> <p> For the access event, you will need to select an action that causes your system to send an audit record. These events could include access to a record, export of data, etc. </p> <p>For evaluation, the Project Manager will examine the logs of the Audit Repository. One example request: Show me a log of all of the login failures. </p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (32, 1, 0, '2009-11-24 10:53:15.964', 'epoiseau', '<H3>Special Instructions</H3>
 <p>Your ATNA Secure Node or Secure Application may not support the HL7 V3 protocol. In that case, skip this test</p>
 <p>The documentation in ITI TF 2:3.19.6.2, 3.19.6.3, and 3.19.6.4 explains us of ciphers for the ATNA profile.  For the 2009 Connectathons, we will follow the ATNA guidelines and allow some extensions.</p>
 <p><u>HTTP communication</u>: Section 3.19.6.3 requires encryption. In order to support your software, we will allow these two ciphers for HTTP communication:
 <ol>
 <li>TLS_RSA_WITH_AES_128_CBC_SHA</li>
 <li>SSL_RSA_WITH_3DES_EDE_CBC_SHA</li>
 </ol>
 <p>This means that you will be responsible to find a partner who supports these ciphers. We will not mandate which ciphers are used by which partners.</p>
 <H3>Description</H3>
 <p>The purpose of the ATNA_Authentication_HL7V3 test is for Secure Nodes or Secure Applications
    that communicate using HL7 V3 (over HTTP/HTTPS) and exchange the proper certificates.</p>
 <p>As a Secure Node or Secure Application at the Connectathon, you need to examine the list of other Secure Nodes and
    find a system that you recognize as a test partner for other tests. Once you have found a
    suitable test partner that uses HTTPS with mutual authentication, you can run this test.</p>
 <p>Evaluation will require the both applications to show log files or other evidence that
    certificates were successfully exchanged and an IHE transaction occurred between the two systems. The transaction is
    allowed to cover a subset of an Integration Profile.</p>
 <H3>Evaluation</H3>
 <p>Connectathon monitor will examine log files of both applications for evidence of certificate
    exchange. Systems should also be able to demonstrate that some transaction was completed (eg PIXv3 query).</p>
 <p>Systems must support defined cyphersuites. These are found in the IHE ITI Technical Framework; refer to the ''Special Instructions'' above.</p>
 <p>The systems under test need to demonstrate only one type of transaction is operational using
    the TLS communication.</p>
 <p>Monitor will want to see : 
 <ul><li>TLS Start or equivalent</li>
 <li>Certificate of both participants</li>
 <li>Successful TLS handshake</li>
 <li>The selected CIPHER Suite</li>
 </ul>
 
 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (33, 1, 0, '2009-11-24 10:53:15.966', 'epoiseau', '<H3>Special Instructions</H3> <p>Your ATNA Secure Node or Secure Application may not support the HTTP protocol. In that case, skip this test</p> <p>The documentation in ITI TF 2:3.19.6.2, 3.19.6.3, and 3.19.6.4 explains us of ciphers for the ATNA profile.  For the NA 2009 Connectathon, we will follow the ATNA guidelines and allow some extensions.</p> <p><u>HTTP communication</u>: Section 3.19.6.3 requires encryption. In order to support your software, we will allow these two ciphers for HTTP communication: <ol> <li>TLS_RSA_WITH_AES_128_CBC_SHA</li> <li>SSL_RSA_WITH_3DES_EDE_CBC_SHA</li> </ol> <p>This means that you will be responsible to find a partner who supports these ciphers. We will not mandate which ciphers are used by which partners.</p> <H3>Description</H3> <p>The purpose of the ATNA_Authentication_HTTP test is for Secure Nodes or Secure Applications    that communicate using HTTP to use HTTPS and exchange the proper certificates.</p> <p>As a Secure Node or Secure Application at the Connectathon, you need to examine the list of other Secure Nodes and    find a system that you recognize as a test partner for other tests. Once you have found a    suitable test partner that uses HTTPS with mutual authentication, you can run this test.</p><p>Evaluation will require the both applications to show log files or other evidence that    certificates were successfully exchanged and an IHE transaction occurred between the two systems. The transaction is    allowed to cover a subset of an Integration Profile.</p> <H3>Evaluation</H3> <p>Connectathon monitor will examine log files of both applications for evidence of certificate    exchange. Systems should also be able to demonstrate that some transaction was completed (eg RID    Query, XDS Submit Document, XDS Register Document, XDS Query).</p> <p>Systems must support defined cyphersuites. These are found in the IHE ITI Technical Framework; refer to the ''Special Instructions'' above.</p> <p>The systems under test need to demonstrate only one type of transaction is operational using    the TLS communication.</p> <p>Monitor will want to see :  <ul><li>TLS Start or equivalent</li> <li>Certificate of both participants</li> <li>Successful TLS handshake</li> <li>The selected CIPHER Suite</li> </ul>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (34, 1, 0, '2009-11-24 10:53:15.969', 'epoiseau', '<H3>Description</H3> <p>The purpose of the ATNAAuthentication test is for Secure Nodes (ATNA or Basic Security) to exchange certificates and then perform communication over the established connection. This implies DICOM, HL7 or other communication over the established connection.</p>  <p>Evaluation will require the both applications to show log files or other evidence that certificates were successfully exchanged and an IHE transaction occurred. The transaction will be a subset of an Integration Profile.</p>  <H3>Evaluation</H3> <p>Connectathon monitor will examine log files of both applications for evidence of certificate exchange. Systems should also be able to demonstrate that some transaction was completed (Patient ADT, MWL worklist query).</p>  <p>The systems under test need to demonstrate only one type of transaction is operational using the TLS communication.</p>    ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (35, 1, 0, '2009-11-24 10:53:15.971', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Your ATNA Secure Node or Secure Application may not support the DICOM protocol. In that case, skip this test.</p> </p> <p>The documentation in ITI TF 2:3.19.6.2, 3.19.6.3, and 3.19.6.4 explains us of ciphers for the ATNA profile.  For the NA 2009 Connectathon, we will follow the ATNA guidelines and allow some extensions.</p> <p><u>DICOM and HL7 Communication</u>: Section 3.19.6.2 lists two ciphers, one with encryption and one without. Understanding that some of you have problems with these ciphers, we will allow the following ciphers for DICOM and HL7 communication during the connectathon:</p> <ol> <li>TLS_RSA_WITH_NULL_SHA</li> <li>TLS_RSA_WITH_AES_128_CBC_SHA</li> <li>SSL_RSA_WITH_3DES_EDE_CBC_SHA</li> </ol> <p>This means that you will be responsible to find a partner who supports these ciphers. We will not mandate which ciphers are used by which partners.</p> <H3>Description</H3> <p>The purpose of the ATNA_Authentication_DICOM test is for Secure Nodes or Secure Applications    to exchange certificates and then perform DICOM communication over the established connection.</p> <p>Evaluation will require the both applications to show log files or other evidence that    certificates were successfully exchanged and an IHE transaction occurred. The transaction is    allowed to cover a subset of an Integration Profile.</p> <p>As a Secure Node or Secure Application at the Connectathon, you need to examine the list of other Secure Nodes/Applications and    find a system that you recognize as a test partner for other tests. Once you have found a    suitable test partner that uses the DICOM protocol over TLS, you can run this test.</p><H3>Evaluation</H3> <p>Connectathon monitor will examine log files of both applications for evidence of certificate    exchange. Systems should also be able to demonstrate that some transaction was completed (MWL   query, DICOM C-Store, etc.). Systems must support defined cyphersuites. These are found    in the IHE ITI Technical Framework; also see Special Instructions above.</p> <p>The systems under test need to demonstrate only one type of DICOM transaction is operational using    the TLS communication.</p>  <p>Monitor will want to see : <ul> <li>TLS Start or equivalent</li> <li>Certificate of both participants</li> <li>Successful TLS handshake</li> <li>The selected CIPHER Suite</li </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (36, 1, 0, '2009-11-24 10:53:15.973', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Your ATNA Secure Node or Secure Application may not support the HL7 V2 protocol. In that case, skip this test.</p> <p>The documentation in ITI TF 2:3.19.6.2, 3.19.6.3, and 3.19.6.4 explains us of ciphers for the ATNA profile.  For the NA 2009 Connectathon, we will follow the ATNA guidelines and allow some extensions.</p> <p><u>DICOM and HL7 Communication</u>: Section 3.19.6.2 lists two ciphers, one with encryption and one without. Understanding that some of you have problems with these ciphers, we will allow the following ciphers for DICOM and HL7 communication during the connectathon:</p> <ol> <li>TLS_RSA_WITH_NULL_SHA</li> <li>TLS_RSA_WITH_AES_128_CBC_SHA</li> <li>SSL_RSA_WITH_3DES_EDE_CBC_SHA</li> </ol> <p>This means that you will be responsible to find a partner who supports these ciphers. We will not mandate which ciphers are used by which partners.</p>  <H3>Description</H3> <p>The purpose of the ATNA_Authentication_HL7_V2 test is for Secure Nodes or Secure Applications    to exchange certificates and then perform HL7 V2 communication over the established connection.</p> <p>Evaluation will require the both applications to show log files or other evidence that    certificates were successfully exchanged and an IHE transaction occurred. The transaction is    allowed to cover a subset of an Integration Profile.</p> <p>As a Secure Node or Secure Application at the Connectathon, you need to examine the list of other Secure Nodes and    find a system that you recognize as a test partner for other tests. Once you have found a    suitable test partner that uses HL7 V2 messaging over TLS, you can run this test.</p><H3>Evaluation</H3> <p>Connectathon monitor will examine log files of both applications for evidence of certificate    exchange. Systems should also be able to demonstrate that some transaction was completed (ADT,    ORM).</p><p>Systems must support defined cyphersuites. These are found in the IHE ITI Technical Framework;  see the notes in the Special Instructions above.</p> <p>The systems under test need to demonstrate only one type of transaction is operational using    the TLS communication.</p>  <p>Monitor will want to see :  <ul> <li>TLS Start or equivalent</li> <li>Certificate of both participants</li> <li>Successful TLS handshake</li><li>The selected CIPHER Suite</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (37, 1, 0, '2009-11-24 10:53:16.026', 'epoiseau', '<H3>Special Instructions</H3>
 <p>Your ATNA Secure Node or Secure Application may not support profiles which use webservices transactions. In that case, skip this test</p>
 <p>The documentation in ITI TF 2:3.19.6.2, 3.19.6.3, and 3.19.6.4 explains us of ciphers for the ATNA profile.  For the 2009 Connectathons, we will follow the ATNA guidelines and allow some extensions.</p>
 <p><u>For Web Services communication</u>: Section 3.19.6.4 points to the WS-I Basic Security Profile Version 1.1. For Web Services, we will accept these ciphers:
 <ol>
 <li>TLS_RSA_WITH_3DES_EDE_CBC_SHA</li>
 <li>SSL_RSA_WITH_3DES_EDE_CBC_SHA</li>
 <li>TLS_RSA_WITH_AES_128_CBC_SHA</li>
 <li>SSL_RSA_WITH_AES_128_CBC_SHA</li>
 </ol>
 <p>This means that you will be responsible to find a partner who supports these ciphers. We will not mandate which ciphers are used by which partners.</p>
 <p>Note: the ciphers starting with SSL vs. TLS are identical (i.e. 1. is exactly the same as 2., and 3. is exactly the same as 4.  The reason for this is because the names are for display purposes only; each cipher has a code that goes on the wire (according to the TLS/SSL specs) and there is only one code for, for example, RSA_WITH_3DES_EDE_CBC_SHA, regardless of the TLS or SSL prefix in the display name.</p>
 <H3>Description</H3>
 <p>The purpose of the ATNA_Authentication_Webservices test is for Secure Nodes or Secure Applications
    that communicate using webservices transactions to exchange the proper certificates.</p>
 <p>As a Secure Node or Secure Application at the Connectathon, you need to examine the list of other Secure Nodes and
    find a system that you recognize as a test partner for other tests. Once you have found a
    suitable test partner that uses webservices with mutual authentication, you can run this test.</p>
 <p>Evaluation will require the both applications to show log files or other evidence that
    certificates were successfully exchanged and an IHE transaction occurred between the two systems. The transaction is
    allowed to cover a subset of an Integration Profile.</p>
 <H3>Evaluation</H3>
 <p>Connectathon monitor will examine log files of both applications for evidence of certificate
    exchange. Systems should also be able to demonstrate that some transaction was completed (eg from the XDS.b, RFD, PIXv3 profiles, among others).</p>
 <p>Systems must support defined cyphersuites. These are found in the IHE ITI Technical Framework; refer to the ''Special Instructions'' above.</p>
 <p>The systems under test need to demonstrate only one type of transaction is operational using
    the TLS communication.</p>
 <p>Monitor will want to see : 
 <ul><li>TLS Start or equivalent</li>
 <li>Certificate of both participants</li>
 <li>Successful TLS handshake</li>
 <li>The selected CIPHER Suite</li>
 </ul>
 ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (38, 1, 0, '2009-11-24 10:53:16.043', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This test is based on a use case involving a series of login and patient record events. The secure node should check with the Project Manager to find the assigned Audit Record Repositories. Then, the secure node should run through the test and make sure all of the events are logged. During the evaluation, the Connectathon monitor will ask the Secure Node to repeat the steps and will examine the logs in the Audit Record Repository in real time.</p> </p><H3>Description</H3><p>This test shows that the Secure Node manages different accounts for different users and can disable accounts when one of the users is no longer employed by the institution. It shows this management by examining audit logs. The log should reference the user accounts specifed below (use those accounts) and the system that is being tested. Indicating in the log that "someone" logged in "to some system" is not acceptable for this test.</p><p>Paul Erker and William Retired are cousins working at the Large Hospital System (LHS). They have login IDs of <strong>erkerp</strong> and <strong>retiredw</strong>. William Retired will retire during the Connectathon week. During the first part of the test, he has access rights; after retirement, those rights are revoked. Please follow these steps for this test.</p><ol> <li>Each Secure Node should create and activate accounts for <strong>erkerp</strong> and <strong>retiredw</strong> for operation on Monday morning or in advance of the Connectathon. This does not require an audit message.</li> <li>On the Secure Node, login as retiredw. This should generate an audit log. The Secure Node should allow William to have access to some data that would generate an audit log. This will be specific to the actor and profiles supported. At least one audit record should be generated <strong>Two audit messages verified by monitor.</strong> </li> <li>On the Secure Node, disable the <strong>retiredw account</strong>. No audit record is required.</li> <li>On the Secure Node, try to login (and fail) as <strong>retiredw</strong>. This should fail and generate an audit record <strong>verified by monitor.</strong> </li> <li>On the Secure Node, login (successfully) as <strong>erkerp</strong>. This should generate an audit record (<strong>verified by the monitor</strong>).</li> </ol><H3>Evaluation</H3><p>Connectathon monitor will observe the Secure Node performing the tasks listed as they occur in real time. The monitor will then examine the Audit Record Repository to see if the proper audit messages are received. It is probably best to examine the Audit Record Repository after each event.</p><p>Monitor is looking for these audit events in this order</p><ol> <li>Successful login for retiredw </li> <li>Access to PHI/patient record for retiredw</li> <li>Login failure for retiredw</li> <li>Successful login for erkerp</li> </ol><p>Login failures should be clearly identified as failures. All events should clearly indicate the user and system that generated the event. Events that include access to PHI should clearly indicate the patient.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (39, 1, 0, '2009-11-24 10:53:16.068', 'epoiseau', '<H3>Special Instructions</H3> ATNA or Basic Security Secure Nodes are required to protect all transactions with TLS communication and generate audit messages for each actor where appropriate. For systems that are combinations of several actors in several profiles, each actor in each profile must be secure for this system to qualify as a secure node.  <H3>Description</H3> This test is performed in the presence of a Connectathon monitor. You need to determine in advance how you are going to demonstrate these actions. <ol> <li> Demonstrate TLS communication for each type of transaction for each actor/profile pair in your system. For example, for a combined Image Manager (SWF) / XDS Repository (XDS), you will have to demonstrate TLS communication for the Scheduled Workflow transactions (Rad-4, Rad-6, Rad-8, Rad-14, Rad-16) and the XDS transactions ('').</li> <li>For each actor/profile combination in your system, generate at least one audit record that is appropriate. Send that audit record to a centralized Audit Record Repository designated by the Connectathon monitor. This is a separate repository that is used only for this test and not during the other tests.</li> </ol> <p>When you are ready to run this test, the Connectathon monitor will clear the Audit Record Repository so only your events are logged. As you run the test, you should indicate which audit records should be recorded in the ARR. As the test progresses (or at the end), the Connectathon monitor will review the records on the ARR and compare to your list. </p> <H3>Evaluation</H3> <p>Connectathon monitor will evaluate in real time with you during this test. You need to demonstrate the appropriate TLS communication and logging to the central ARR.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (40, 1, 0, '2009-11-24 10:53:16.072', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Each ATNA Secure Node or Secure Application runs <b>     <u>one instance</u>    </b> of this test.  For NA2009 Connectathon, if your system has qualified for Supportive testing, you do not need to complete the questionnaire and the interview, but you do need to complete the logging portion of this test.</p> <p>The ATNA profile has specific requirements for secure communication (TLS) and logging. There    are other requirement that describe how you protect and monitor your system. These other    requirements are best addressed with an interview process.</p> <p> A Connectathon Monitor will visit your system and ask questions that are listed in the <i><a href="http://ihewiki.wustl.edu/wiki/images/d/d9/ATNA_Inquisition_Questionnaire_6.doc">ATNA_Inquisition_Questionnaire</a></i>. The goal of the interview/inquisition    is for the Connectathon Monitor to determine if you have met the ATNA requirements for securing    your system.</p> <p>You will save yourself and the monitor valuable time during the connectathon if you complete a    draft of the questions in the form <b>prior</b> to arriving at the connectathon. It is available    at the same time this test is published. You are encouraged to read the form and fill in as much    information as possible in advance of the    Connectathon.  Upload your completed questionnaire into 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>.  Uploading the form is an indication to the connectathon monitor that you are ready for the interview. </p>  <H3>Description</H3> <p>There are 2 parts to the ATNA Inquisition test:</p><ol start="1" type="1">     <li>      <p> <strong>An oral interview</strong> with a Connectathon Monitor during Connectathon week using      the questions in Section 2 of the ATNA_Inquisition interview form. At the Connectathon, you can      speed up the process greatly by having this form with you at the Connectathon, already printed      with as much information entered as possible. If nothing else, notes to yourself on the      applicability of the Audit messages would help you during the interview process. If you can      fill out the form in advance of the Connectathon, so much the better. </p>     </li>     <li>      <p> <strong>Connectathon Monitor review of Audit Message(s)</strong> sent to a central Audit      Record Repository (the NIST Repository). See details in section 3 of the ATNA_Inquisition form. </p>     </li> </ol><p> Based on the results of this test, the monitor will indicate if he/she believes the system    qualifies as an ATNA Secure Node, the ATNA Secure Application or neither. These results are    recorded in Section 1 of the form and entered into kudu as the results for this test.</p> <H3>Evaluation</H3> <p>The Connectathon Monitor will complete the interview form and mark this test as ''passed'' if you    meet the audit requirements for your specific application and successfully send the requested    audit message(s).</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (41, 1, 0, '2009-11-24 10:53:16.078', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Each Secure Node and Secure Application runs <b>one instance</b> of this test.</p> <p>ATNA_Logging is a supplement to the ATNA_Inquisition test. Secure nodes need to run this test    as well as it will give you experience with more than one Audit Record Repository.</p> <p>The Reliable Syslog protocol has been placed on hold by the ITI Technical Committee; only the    BSD syslog protocol shall be used.</p> <p>ATNA allows the Secure Node to select from two different schemas. However, the Secure Node    should not mix schemas; it should implement one schema for the system. Audit Record Repository    actors are required to support both schemas.</p> </p><H3>Description</H3> <p>The purpose of the ATNA_Logging test is for your ATNA Secure Node or Secure Application to send    one or more audit messages to an Audit Record Repository. At the Connectathon, it is likely you    will be assigned to work with a specific Audit Record Repository. Please use your assigned    Repository. The type of audit message depends on the nature of the Secure Node/Application.</p><p>The top priority for testing would be an event that involves access to PHI that would result in    an audit message that includes a Patient ID. We have a well known patient to use, and want the    Secure Nodes to generate an event for that patient if possible.</p><p>If the Secure Node does not generate an audit message that includes a patient ID, we will    accept a different audit message.</p><p>Assuming a PHI event, the Secure Node should generate an audit record with the patient ID that    corresposponds to the well know patient FARNSWORTH^STEVE. This global ID is fixed by the    Connectathon test plan: 101^^^IHE and 1.3.6.1.4.1.21367.2009.1.2.300 and ISO^PI.</p><p>If your system generates an audit record using a local ID for FARNSWORTH, make sure you inform    the Connectathon monitor. The test steps list both audit message schemas; run the test with a    single schema. That means you will omit one test step.</p><H3>Evaluation</H3><p>For a PHI related log message, the Connectathon Monitor will ask the Audit Record Repository    for a list of PHI related events for the FARNSWORTH patient from the Secure Node that    participated in the test.</p><p>If the Secure Node does not generate an event with the FARNSWORTH patient ID, the Connectathon    Monitor will ask the Audit Record Repository to show the last one or two log messages from the    Secure Node.</p><p>     <strong>NB: For some systems that do not have the assigning authority (e.g., Imaging PACS), send     the audit message with that field empty.</strong> </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (42, 1, 0, '2009-11-24 10:53:16.084', 'epoiseau', '<H3>Special Instructions</H3> <p>A Secure Node is allowed to choose one or both of the audit record formats; select the one for testing that you have implemented (or test both). The test is written to list both transport mechanisms; we intended to only test the BSD/UDP transport. The Secure Syslog is undergoing further review.</p> <p>Even though this test will not be evaluated, please perform the test and record the results accurately. This will help the Project Managers inform the Technical Committees of the schemas that are actually used to send audit messages.</p>  <H3>Description</H3> <p>The ATNA Integration Profile supports two transports: BSD Syslog and Reliable Syslog. It also supports two schema definitions: IHE Provisional (Radiology Year 4) and the schema found in RFC 3881 Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications. The Radiology Basic Security profile supports only BSD Syslog and the IHE Provisional schema.</p>  <p>The purpose of this test is to have a Secure Node actor generate one event and communicate that event to the Audit Repository. There are multiple steps to the test to differentiate those choices. You only need to complete the step or steps that apply to you. You do need to complete at least the first step (generate an event) and one of the following steps (send the message using a combination of transport and schema definitions).</p>  <p>This test is preparation for later tests. Perform this test with each repository to make sure the transport is working. You can submit this test in the Kudu web tool, but DO NOT ask a Connectathon monitor for evaluation.</p>  <H3>Evaluation</H3> There is no evaluation for this. This will be evaluated in later, workflow tests. ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (43, 1, 0, '2009-11-24 10:53:16.086', 'epoiseau', '<H3>Special Instructions</H3> <p> One Connectathon monitor will use the RIS Mall to generate a single Patient ID for our subject. This Patient ID will be used by all systems to simplify reporting. <B>Do not generate your own ID for this patient; it will make tracking impossible. Use the Patient ID assigned by the Connectathon monitor. Find the ID by examining IHE-News for a message on this server.</B></p>  <p>This test uses the name and concept of a VIP (Very Important Person). That does not mean your system needs to take special measures to know this person is a VIP. Perhaps we are performing a routine audit 6 months after the fact on random patients. The purpose of the test is to track access to a specific patient and see how the Audit Record Repositories can assist an auditor in finding those events.</p>  <p>In most Connectathon tests, we allow client applications to drive the process. In this test, we ask Connectathon monitors to drive the process. They will assign specific clients (Secure Nodes) to Audit Record Repositories and ask the Secure Nodes to send the audit message to those repositories. As the audit records are sent, the Connectathon monitor will ask the Audit Record Repository to show evidence that the record was properly sent, formatted and stored.</p> <H3>Description</H3> <p>It is a beautifal Connectathon afternoon, and Harry Potter has just fallen off his broomstick while competing in the final Quidditch match of the school year. Foul play is suspected, but a blinding light was cast just at the instant Harry fell from the sky.</p>  <p>Harry has been taken to the infirmary under the watchful eye of Professor McGonagall. After a full battery of tests, Harry is referred to St. Mungo''s Hospital for Magical Maladies and Injuries. There he will see a specialist to determine if he is the victim of a spell.</p>  <p>All of the information systems at the Hogwarts School allow access to all patient records and use auditing to detect undesirable behavior. Your Secure Node is one such information system. Determine some action that will trigger an audit record indicating someone on your system <b>(Secure Node)</b> is viewing a medical record for Harry Potter.</p>  <p>Create a character on your system, login with that character name and trigger the auditing event. This should send the event to an Audit Record Repository.</p>  <p>Professor Dumbledore suspects Hogwarts staff members are improperly trying to view Harry''s records. He consults with the Audit Record Repository and asks to see log/access records from the Secure Node that indicate access to the Harry Potter account.</p>  <p>Specific steps <ul> <li>Secure nodes find the Connectathon monitor(s) in charge of security/audit records. Find which Audit Record Repository or repositories are designated to receive audit records.</li> <li>Audit Record Repositories should also determine which clients are required to send them messages.</li> <li>Secure Node generates one (or more) audit record that indicates access to the patient record for Harry Potter (patient ID assigned by the Connectathon monitor).</li> <li>After Secure Node checks with Audit Record Repository to see the audit record was received/stored, repeat the auditing step in the presence of the Connectathon monitor.</li> <li>Connectathon monitor will then consult with Audit Record Repository to examine the audit record.</li> </ul> <H3>Evaluation</H3> <p>In the real world, a security officer would ask the Audit Record Repository to generate a report or produce evidence that can be used to determine who has had access to the Harry Potter record in the last N days.</p> <p>In the Connectathon, the Connectathon monitor should examine the Audit Record Repository for evidence of the Audit Record as soon after the access to PHI has occurred as possible. This will simplify the job of the monitor (concentrate on individual systems) and will allow the client to know the reocrd has been reviewed.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (44, 1, 0, '2009-11-24 10:53:16.089', 'epoiseau', '<p>Secure Node actors perform standalone operations or communicate with other Secure Node actors. As a consequence of these actions, these actors generate audit records that are sent to an Audit Record Repository. At least 3 audit records should be sent and observed at the Audit Record Repository: <ol><li>Actor start</li><li>Actor stop</li><li>One record that shows some type of access by the system. This could be a modality starting to send instances, or an image manager responding to a query or something different</li></ol></p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (45, 1, 0, '2009-11-24 10:53:16.094', 'epoiseau', '<H3>Special Instructions</H3><p> <p>An XDS.a/.b Document Source or XDR Document Recipient must run this test if it supports BPPC, ie it supports the Basic Patient Privacy Enforcement option.   This is a test where the Document Source interprets/enforces a privacy policy in document it retrieves (eg a Medical Summary). <p>BPPC Document Sources must run test <b>BPPC_Source_Enforcement </b> before this test can be    run.  Document Sources have no work to do in this test, but are included as an actor in this test so that they get credit when Document Consumers process the documents they applied the consent policies to.</p> <p>A Document Consumer must run this test if you support BPPC, ie you support the Basic Patient    Privacy Enforcement option. </p> </p><H3>Description</H3><p>In this test, the Document Consumer queries for documents for two patients:</p><ul>     <li>BPPCNormal^[source_system_name]</li>     <li>BPPCRestricted^[source_system_name]</li> </ul><p>After the query, the Document Consumer should display documents to the user (if the policy    allows it).</p><p> All Affinity Domains at the Connectathon have the following two privacy policies which    patients can choose from:</p><ul>     <li>The ''Normal Policy'' (Normal Sharing for Treatment) have the     confidentiality policy specified by the OID 1.3.6.1.4.1.21367.2006.7.107 </li>     <li>The ''Restricted Policy'' (Sensitive Restricted Sharing) have the     confidentiality policy specified by the OID 1.3.6.1.4.1.21367.2006.7.109 </li> </ul> <p>The Document Consumer should show documents for the Normal patient and NO documents for the    patient who chose the Restricted policy.</p> <H3>Evaluation</H3> <p>The monitor should observe the Document Consumer in real time performing the query and    retrieving documents. The monitor should observe documents displayed for the Normal patient. If    any documents are displayed for the Restricted patient, that is a failure.</p> <p>The monitor may ask the Document Source to show how Privacy Consent policies are configured on    its system, and how it determines how to enforce confidentiality codes in the Affinity   Domain.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (46, 1, 0, '2009-11-24 10:53:16.097', 'epoiseau', '<H3>Special Instructions</H3><p> <p>BPPC Content Consumers must run test <b> BPPC_Content_Consumer </b> before this test can be run</p> <p>BPPC Document Consumers which support the <b>Basic Patient  Privacy Proof option</b> run <strong>one instance </strong>of  this test.</p> </p> <H3>Description</H3> <p>In this test, the Document  Consumer uses the Registry Stored Query Transaction to query for Patient  Privacy Consent Acknowledgment Documents. This should be done by document classCode  (classCode=Consent). </p> <p>For every BPPC Content Creator at the Connectathon, ''Consent documents should exist for two  patients (the patients'' first name is the Content Creator''s kudu system name):</p> <ul>     <li>NormalConsent^[system-name]</li>     <li>RestrictedConsent^[system-name]</li> </ul> <H3>Evaluation</H3> <p>The monitor should observe the Document Consumer in real time performing the query for Consent documents.  Consumers are *not* required to be able to retrieve the consent documents.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (47, 1, 0, '2009-11-24 10:53:16.103', 'epoiseau', '<H3>Special Instructions</H3><p>  <p>Content Consumers please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find the sample BPPC document(s) your peers have submitted. </p> <p>The BPPC Content Creators must run test<b> BPPC_Content_Creator </b>before this test can be run.  Content Creators have no work to do in this test, but are included as an actor in this test so that they get credit when Content Consumers display the contents of the Consent documents they created in the earlier test.</p> <p>BPPC Content Consumers  run this test to demonstrate their ability to display  ''Patient Privacy Consent Acknowlegement'' documents made by Content Creators as specified in ITI TF-2:5.1.2 and TF-2:5.1.3.</p> <p>BPPC Content Consumers must support the <b>Basic Patient Privacy Acknowledgement View </b>option. </p> </p><H3>Description</H3><p> <p>This is a test of the display of a patient''s Consent  document per the BPPC profile.  The  application of the restrictions in privacy consents on other documents for this  patient is tested in another test.</p>     <p>BPPC Content Consumers are not required to use XDS/XDM/XDR  to retrieve Consent documents, but many Content Consumers will have this  capability, and we will use it in the test where possible.</p>     <p>In this test, the Content Consumer actor displays Consent  created in test <strong>BPPC_Content_Creator</strong> for patients as follows (the patient''s  first name is the Content Creator''s system name in kudu):</p>     <ul>      <li>NormalConsent^[system-name]</li>      <li>RestrictedConsent^[system-name]</li>     </ul>     <p>If possible, the Content Consumer will retrieve  the document.</p> </p> <H3>Evaluation</H3> <p>The monitor will examine the two Patient Privacy  Acknowledgement documents as they''re displayed on the Content Consumer''s  application.  The BPPC profile requires  display capabilities of the Content Consumer actor; the system must demonstrate  a reasonable rendering of the contents of the Consent document.  If the Content Consumer can only retrieve the  document into its database, but not display it, it will fail this test.</p><p>The Consent documents contain:</p><ul>     <li>An ''author''; this is the patient, guardian or  legal guardian issuing the consent acknowledgement.</li>     <li>A text description of what the patient consented  to.  It should differ in the two documents</li>     <li>Once code indicating the policy agreed to; the  two documents should contain different codes - Normal and Restricted</li>     <li>The effective dates of this consent is  specified.   If the Content Creator has  this capability, the ''normal'' consent should be in effect for the week of the  connectathon, and the ''Restricted'' consent should be in effect for the current  calendar year.</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (48, 1, 0, '2009-11-24 10:53:16.11', 'epoiseau', '<H3>Special Instructions</H3><p> <p>Content Creators should run this test on the first day of  the Connectathon.</p> <p>Content Creators in the BPPC Profile run one instance of  this test to demonstrate their ability to create a ''Patient Privacy Consent  Acknowlegement'' document with content as specified in ITI TF-2:5.1.2 or ITI TF-2:5.1.3</p> <p>The Content Creator may support either the Basic Patient  Privacy Acknowledgement option (ie with no scanned document content) or the  Basic Patient Privacy Consent Acknowledgement with Scanned Document  option.  </p> </p> <H3>Description</H3> <p>This is a test of the creation of a patient''s Consent  document per the BPPC profile.  The application  of the restrictions in privacy consents on other documents for this patient is  tested in another test.</p> <p>BPPC Content Creators are not required to use XDS/XDM/XDR  to submit their content, but many Content Creators will have this capability, and we will use it in the  test where possible.</p> <p>All Affinity Domains at the Connectathon have the  following two privacy policies which patients can choose from:</p><ul>     <li>The ''Normal Policy'' (Normal Sharing for Treatment) have the confidentiality policy specified by the OID  1.3.6.1.4.1.21367.2006.7.108 </li>     <li>The ''Restricted Policy'' (Sensitive Restricted  Sharing) have the confidentiality policy specified by the OID  1.3.6.1.4.1.21367.2006.7.109 </li> </ul><p>In this test, the Content Creator actor creates Consent documents  for two patients as follows (the patient''s first name is the Content Creator''s  system name in kudu):</p><ul>     <li>NormalConsent^[system-name]</li>     <li>RestrictedConsent^[system-name]</li> </ul> <p>Store the document and reference information in the Kudu tool. You will find the page in the Kudu tool by selecting Connectathon and then Connectathon Images/CDs/Objects. The link to that page is <em><a href=system_con_object.php>Objects Information</a></em> </p>  <p>If possible, the Content Creator will submit the document  via XDS/XDM/XDR.</p> <H3>Evaluation</H3> <p>The connectathon monitor may ask the Content Creator to  demonstrate the process of creating a Patient Privacy Consent Acknowlegement  document with its system.</p> <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. This  may also be done by using a Document Consumer to retrieve the Consent Document from the Document Repository.</p> <p>The monitor will examine the two Patient Privacy  Acknowledgement Documents stored in the Repository for patients NormalConsent^[system_name]  and RestrictedConsent^[system_name].  </p> <p>The Consent documents shall contain:</p><ul>     <li>An ''author''; this is the patient, guardian or  legal guardian issuing the consent acknowledgement.</li>     <li>A text description of what the patient consented  to.  It should differ in the two documents.</li>     <li>One code indicating the policy agreed to; the two documents should contain different codes; see test description</li>     <li>The effective dates of this consent is  specified.   If the Content Creator has  this capability, the ''normal'' consent should be in effect for the week of the  connectathon, and the ''Restricted'' consent should be in effect for the current  calendar year.</li> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (49, 1, 0, '2009-11-24 10:53:16.112', 'epoiseau', '<H3>Special Instructions</H3><p> <p>An XDM Portable Media Creator must run this test if it supports BPPC, ie it supports the Basic Patient    Privacy Enforcement option. This is a test where the Portable Media Creator (PMC) applies a privacy policy to    document it writes to XDM media (eg a Medical Summary). This is not a test where the PMC creates a    patient''s Consent document; that is test <b>BPPC_Content_Creator</b>.</p> </p><H3>Description</H3><p>The XDM Portable Media Creator actor which support the Basic Patient Privacy Enforcement option populates    the confidentialityCode in the document metadata with the list of OID values that identify the    Patient Privacy Consent Policy(ies) that apply to the associated document. </p><p>All Affinity Domains at the Connectathon have the following two privacy policies which patients    can choose from:</p><ul>     <li>The ''Normal Policy'' (Normal Sharing for Treatment) have the     confidentiality policy specified by the OID 1.3.6.1.4.1.21367.2006.7.107 </li>     <li>The ''Restricted Policy'' (Sensitive Restricted Sharing) have the     confidentiality policy specified by the OID 1.3.6.1.4.1.21367.2006.7.109 </li> </ul><p>The Portable Media Creator creates documents for two patients:</p><ul>     <li>BPPCNormal^[PMC_system_name]</li>     <li>BPPCRestricted^[PMC_system_name]</li> </ul><H3>Evaluation</H3><p>The monitor will examine the documents on the media to examine the confidentiality codes for the two patients.</p><p>The monitor may ask the Portable Media Creator to show how Privacy Consent policies are configured on    its system, and how it determines which confidentiality codes to apply to a given document.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (50, 1, 0, '2009-11-24 10:53:16.122', 'epoiseau', '<H3>Special Instructions</H3><p> <p>BPPC Portable Media Creators (PMC) must run test <b>BPPC_Portable_Media_Creator_Enforcement </b> before this test can be    run.  PMCs have no work to do in this test, but are included as an actor in this test    so that they get credit when Portable Media Importers process the documents they applied the consent    policies to.</p> <p>A Portable Media Importer must run this test if you support BPPC, ie you support the Basic Patient    Privacy Enforcement option. </p> </p> <H3>Description</H3> <p>In this test, the Portable Media Importer imports documents for two patients:</p>  <ul>     <li>BPPCNormal^[PMC_system_name]</li> <li>BPPCRestricted^[PMC_system_name]</li> </ul> <p>After the import the Portable Media Importer should display documents to the user (if it has display capabilities and if the policy    allows it).</p> <p> All Affinity Domains at the Connectathon have the following two privacy policies which    patients can choose from:</p> <ul> <li>The "Normal Policy" (Normal Sharing for Treatment) have the     confidentiality policy specified by the OID 1.3.6.1.4.1.21367.2006.7.107 </li> <li>The "Restricted Policy" (Sensitive Restricted Sharing) have the     confidentiality policy specified by the OID 1.3.6.1.4.1.21367.2006.7.109 </li> </ul> <p>The Portable Media Importer should import documents for the Normal patient and not import documents for the    patient who chose the Restricted policy.</p> <H3>Evaluation</H3> <p>The monitor should observe the Portable Media Importer in real time importing documents. The monitor should observe documents imported/displayed (but display is not required) for the Normal patient only. If    any documents are imported for the Restricted patient, that is a failure.</p> <p>The monitor may ask the Portable Media Importer to show how Privacy Consent policies are configured on    its system, and how it determines how to enforce confidentiality codes in the Affinity   Domain.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (51, 1, 0, '2009-11-24 10:53:16.125', 'epoiseau', '<H3>Special Instructions</H3><p> <p>A Document Source (in XDS.a, XDS.b) must run this test if it supports BPPC, ie it supports the Basic Patient Privacy Enforcement option.   This is a test where the Document Source applies a privacy policy to document it submits (eg a Medical Summary).  This is not a test where the Source creates a patient''s Consent document; that is test <b>BPPC_Content_Creator</b>.</p> </p><H3>Description</H3><p>The Document Source actor which support the Basic Patient  Privacy Enforcement option populates the confidentialityCode in the document  metadata with the list of OID values that identify the Patient Privacy Consent Policy(ies) that apply to the associated document. </p><p>All Affinity Domains at the Connectathon have the  following two privacy policies which patients can choose from:</p><ul>     <li>The  ''Normal Policy'' (Normal Sharing for Treatment) have the confidentiality policy  specified by the OID 1.3.6.1.4.1.21367.2006.7.107 </li>     <li>The  ''Restricted Policy'' (Sensitive Restricted Sharing) have the confidentiality  policy specified by the OID 1.3.6.1.4.1.21367.2006.7.109 </li> </ul><p>The Document Source registers documents for two patients:</p><ul>     <li>BPPCNormal^[source_system_name]</li>     <li>BPPCRestricted^[source_system_name]</li> </ul><H3>Evaluation</H3><p>The monitor will ask the registry to show the confidentiality codes for the two patients. Or, the monitor will query the registry with a tool to examine the codes.</p><p>The monitor may ask the Document Source to show how Privacy Consent policies are configured on its system, and how it determines which confidentiality codes to apply to a given document.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (52, 1, 0, '2009-11-24 10:53:16.128', 'epoiseau', '<H3>Special Instructions</H3><p> <p>An XDR Document Source must run this test if it supports BPPC, ie it supports the Basic Patient Privacy Enforcement option.   This is a test where the Document Source applies a privacy policy to document it submits (eg a Medical Summary).  This is not a test where the Source creates a patient''s Consent document; that is test <b>BPPC_Content_Creator</b>.</p> </p> <H3>Description</H3> <p>The Document Source actor which support the Basic Patient Privacy Enforcement option populate the confidentialityCode in the document  metadata with the list of OID values that identify the Patient Privacy Consent Policy(ies) that apply to the associated document. </p> <p>All Affinity Domains at the Connectathon have the following two privacy policies which patients can choose from:</p><ul>     <li>The  ''Normal Policy'' (Normal Sharing for Treatment) have the confidentiality policy  specified by the OID 1.3.6.1.4.1.21367.2006.7.108 </li>     <li>The  ''Restricted Policy'' (Sensitive Restricted Sharing) have the confidentiality  policy specified by the OID 1.3.6.1.4.1.21367.2006.7.109 </li> </ul><p>The Document Source registers documents for two patients:</p><ul>     <li>BPPCNormal^[source_system_name]</li>     <li>BPPCRestricted^[source_system_name]</li> </ul> <H3>Evaluation</H3>  <p>The monitor may ask the Document Source to show how Privacy Consent policies are configured on its system, and how it determines which confidentiality codes to applied  to a given document.</p> <p>The monitor may ask the Document Recipient to show how it configures Privacy Consent policies and how they''re enforced on its system. <p>On the Document Recipient, the monitor should observe documents displayed for the Normal patient. If    any documents are displayed for the Restricted patient, that is a failure.</p> <p> The monitor may ask to see the exchange of other documents between the Doc Source and Recipient real-time.</p>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (53, 1, 0, '2009-11-24 10:53:16.151', 'epoiseau', '<p>The purpose of this test is to verify the Image Display of variety of ECHO image sets from various vendors.</p>  <p>The Image  Display shall display every image loop of every study and verify the image encoding and patient demographics are accurate.</p>  <p>We are not testing the query and retrieve of images, we are testing the ability of the ID to correctly renter the images. The central archive can be used to store  set of images from different vendors. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (54, 1, 0, '2009-11-24 10:53:16.157', 'epoiseau', '<H3>Special Instructions</H3> None.  <H3>Description</H3> The purpose of this test is to verify that an Image Manager can accept and store all real world vendor images which are available.  <H3>Evaluation</H3> Verify that all images are received and can be queried and retrieved from the IM under test. Verify the total number of SOP instances stored and total number of studies stored.  Verify that the objects are stored as full-fidelity objects (ie., no DICOM data elements are deleted). ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (55, 1, 0, '2009-11-24 10:53:16.167', 'epoiseau', '<p>Ideally, there would be a hemodynamic (HD) and an angio (XA) modality available for these tests; however, that will most likely not be the case.  If there is no HD modality available, execute with only a single modality for a cath lab.  In the real world, this is analogous to the hemo system being non-IHE compliant.</p>  <p>This test primarily tests the DSS/OF ability to handle the complexities of CARD-1 transaction. Specifically, this test tests CATH Use Cases C3 and C5 ability to create Requested Procedures and SPSs on the fly with the correct Study Instance UID from the Modality.</p>  <p>Modality performs an unscheduled procedure. Order Filler dynamically creates a Requested Procedure/Scheduled Procedure Step for that modality and any other modalities in that lab. Image Manager may or may not also participate.   The MPPS Mgr can be combined with either the DSS/OF or the IM in these test cases, but only one MPPS Mgr should be active at one time and it should be recorded which MPPS Mgr was used.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (56, 1, 0, '2009-11-24 10:53:16.177', 'epoiseau', '<p>C-MOD_IM_CATH tests the interactions between Acquisition Modalities and Image Managers. The specific modalities included in this test are XA, HD or IVUS.</p>  <p>Modality performs different procedures (with different MPPS cases) and communicates those results with the Image Manager.  This test assumes that the MPPS Mgr is associated with the IM.  The IM/MMPS Mgr does not need to forward the MPPS messages to the OF for this test.</p>  <p>If you find a DSS/OF that wishes to participate, run the C-MOD_IM_DSS/OF test instead of this one. Note that this test case does NOT test the complexities of the DSS/OF for the CARD-1 transaction.   See the C-MOD_IM_DSS/OF tests.</p>  <P>For evaluation, the Project Manger should visit the Image Manager and ask for evidence that all imaging steps were performed as requested. The Image Manager should so logs or user interface functions that indicate MPPS messages were received (IN PROGRESS, COMPLETE, DISCONTINUED). Image Managers with embedded displays should display images from the modality. Image Managers without displays can show evidence the images were stored (database entries, other GUI) or can direct the Project Manager to an external (other) Image Display.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (57, 1, 0, '2009-11-24 10:53:16.18', 'epoiseau', '<p>Modality performs different procedures (with different MPPS cases) and communicates those results with the Image Manager.  This test assumes that the MPPS Mgr is associated with the IM.  The IM/MMPS Mgr does not need to forward the MPPS messages to the OF for this test.</p>  <p>If you find a DSS/OF that wishes to participate, run the MOD_IM_DSS/OF test instead of this test. Note that this test case does NOT test the complexities of the DSS/OF for the CARD-1 transaction.   See the MOD_IM_DSS/OF tests.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (58, 1, 0, '2009-11-24 10:53:16.185', 'epoiseau', '<p>Ideally, there would be a hemodynamic (HD) and an angio (XA) modality available for these tests, however, that will most likely not be the case.  If there is no HD modality available, execute with only a single modality for a cath lab.  In the real world, this is analogous to the hemo system being non-IHE compliant.</p>  <p>This test primarily tests the DSS/OF ability to handle the complexities of CARD-1 transaction, but also tests the modalities ability to handle the various MPPS cases.</p>  <p>Modality performs different procedures (with different MPPS cases) and communicates those results with the Order Filler. Image Manager also participates.   The MPPS Mgr can be combined with either the DSS/OF or the IM in these test cases, but only one MPPS Mgr should be active at one time and it should be recorded which MPPS Mgr was used.</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).  Demonstrate to the test observer that the DSS/OF is correctly creating and/or cancelling additional SPSs as necessary.</p>  <p>Note that the additional SPS defined below can be dynamically created by the DSS/OF if that is how the system is configured.   The end result must be as shown, however. This test tests CATH Use Cases C1, C2 and C7.</p>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (59, 1, 0, '2009-11-24 10:53:16.187', 'epoiseau', '<p>This test primarily tests the DSS/OF ability to handle the complexities of CARD-1 transaction, but also tests the modalities ability to handle the various MPPS cases.</p>  <p>Modality performs different procedures (with different MPPS cases) and communicates those results with the Order Filler. Image Manager also participates.   The MPPS Mgr can be combined with either the DSS/OF or the IM in these test cases, but only one MPPS Mgr should be active at one time and it should be recorded which MPPS Mgr was used.</p>  <p>This test tests ECHO Use Cases E1, E2, E3, and E4.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (60, 1, 0, '2009-11-24 10:53:16.189', 'epoiseau', '<H3>Special Instructions</H3> Evidence Creators should test <b>all SOP classes it is capable of generating</b>. If the Evidence Creator is grouped with an Acquisition Modality, it should run test <b>STRESS/CATH/ECHO_MODALITY_IM_Interface </b>instead of this one. <H3>Description</H3> This tests workflow transactions between an Evidence Creator and an Image Manager/Archive.  The Evidence Creator creates evidence objects and sends them to the Image Manager. The Evidence Creator will also perform MPPS and Storage Commitment (required for Cardiology STRESS, CATH & ECHO profiles; optional for Radiology SWF profile).  The Q/R and display capabilities are tested in test STRESS/CATH/ECHO_ID_IM. <H3>Evaluation</H3> On the <b>Image Manager</b>:  <ul> <li>Verify that all created objects were successfully stored.  <li>If applicable, verify that the derived objects were created in a new series, and not extended from the series containing the source waveforms or images. <li>View a copy of the PPS and Storage Commitment message from the Evidence Creator, captured on the IM. </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (61, 1, 0, '2009-11-24 10:53:16.19', 'epoiseau', '<H3>Special Instructions</H3> The Intermittently Connected Modality option is required for Image Managers in both the STRESS and ECHO profiles.  If an Image Manager participates in both profiles, this test only needs to be executed once with an ECHO vendor and once with an ECG or NM Modality vendor. <H3>Description</H3> This test verifies Image Managers can queue Storage Commitment N-EVENT-REPORT messages for INTERMITTENTLY CONNECTED MODALITIES, especially Echo and STRESS (CARD-TF-2:4.3.1).  <H3>Evaluation</H3> On the <b>Image Manager</b> verify:  <ul> <li>By viewing captured messages in a log file named [test-case-no]-assocneg.txt, that, after the modality was reconnected, association negotiation from the modality triggered the IM to initiate a separate association to the modality to send queued N-EVENT-REPORT messages.  <li>All SC N-EVENT-REPORT messages have been sent from the IM to the Echo modality.  </ul> On the <b>Modality</b> verify:  <ul> <li>Storage Commitment N-EVENT-REPORT messages (transaction CARD-3) were received at the Modality by viewing the captured message, eg in [test-case-no]-sc.txt.  </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (62, 1, 0, '2009-11-24 10:53:16.192', 'epoiseau', '<H3>Special Instructions</H3> <p>The Image Display may use the Connectathon CENTRAL_ARCHIVE as a source of different vendors'' images and reports </p> <p>Image Display please use the <em><a href=system_con_object.php>Objects Information</a></em> page to find out what your peers have uploaded on the central archive </p> <H3>Description</H3> The test verifies that the Image Display can retrieve and display a variety of image sets, DICOM SRs and Procedure Logs from various vendors. <H3>Evaluation</H3> On the <b>Image Display</b>  <ul> <li>verify that images from each Modality vendor can be accurately stored and displayed.  The Connectathon Monitor may ask a representative of the originating Modality to verify the accuracy of the rendering of its study on the Image Display. <li>The Connectathon Monitor should observe its ability to interpret/render the objects (derived images, SRs, procedure logs, or measurements, ie Evidence Documents) from the Evidence Creator actors. The Connectathon Monitor may ask a representative of the originating Evidence Creator to verify the accuracy of the rendering of its data, or observe the originals at the Evidence Creator and spot-check that they are displayed correctly and completely.   </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (63, 1, 0, '2009-11-24 10:53:16.194', 'epoiseau', '<H3>Special Instructions</H3> To aid in evaluation, it is in your best interest to begin with an image or Modality Worklist where most of the information listed below is known to be present, otherwise you will spend a significant amount of time justifying the absence of the information. <p>If possible, but not required, use the patient naming convention of:  CATH-EC-COMPANYCREATOR^COMPANYPACS, e.g., if it were a Philips modality and a Sectra PACS the patient name might be: CATH-EC-PhilipsIU33^SectraPACS </p> <H3>Description</H3> <p> The CATH_EvidenceCreator_PACS test exercises the Cath Workflow Profile transactions between an Evidence Creator, an Image Manager/Image Archive and an Image Display. In the Cath Workflow Documents profile, the Evidence Creator must perform a Performed Procedure Step and then  produce these documents (SR reports, not images) and store them on the Image Manager. These documents must also be committed using the Storage Commitment transaction.   </p> <p>The Image Display must be able to render and display all Templates for the SOP Classes which they accept. </p> <p> A Modality must produce documents from the following list and an Image Manager must be able to store those documents for the Cath Option: </p> <ul> <li>Enhanced SR <li>Comprehensive SR <li>Procedure Log </ul> <p> The Cath Option Templates include: </p> <ul> <li>3001 Procedure Log <li>3202 Ventricular Analysis <li>3213 Quantitative Arterial Analysis <li>3250 Intravascular Ultrasound <li>3500 Hemodynamics </ul>  <p> All supported SOP Classes and all supported Templates within those SOP Classes must be tested and verified.    </p> <H3>Evaluation</H3> In the Kudu chat window, record all SOP Classes and all Templates which were tested, including all Patient Names, Patient IDs, and Study Instance UIDs for locating information at a later time for verification. <p>  The Connectathon monitor should observe evidence from the <b>Image Manager</b> that these documents were stored. This can be a display on the Image Manager, a 3rd party display or logs or database on the Image Manager if no display is readily available.  At the Image Manager, all of the following attributes of the Structured Report object from the Modality shall be verified to match the original image or MWL information:   (see Rad TF Vol2: Append A, Table A.2-1 and section A.3): </p> <p> <strong>Verify MPPS Message:</strong> </p> <pre> Study Instance UID  (0020, 000D) Scheduled Step Attributes Sequence (0040, 0270) 	>Study Instance UID  (0020, 000D) 	>Referenced Study Sequence (0008, 1110) 	>Accession Number  (0008, 0050) 	>Requested Procedure ID (0040, 1001) 	>Requested Procedure Description (0032, 1060) 	>Scheduled Procedure Step ID (0040, 0009) Performed Protocol Code Sequence (0040, A372) Study ID  (0020, 000D) Performed Procedure Step ID  (0040, 0253) Performed Procedure Step Start Date (0040, 0244) SOP Class UID  (0008, 1150) SOP Instance UID  (0008, 1155) Patient Name   (0010, 0010) Patient ID   (0010, 0020) Patient''s Birth Date (0010, 0030) Patient''s Sex  (0010, 0040) Referring Physicians Name (0008, 0090) </pre> <p> <strong>Verify Structured Report object:</strong> <pre> Study Instance UID  (0020, 000D) Referenced Request Sequence  (0040, A370) 	>Study Instance UID  (0020, 000D) 	>Referenced Study Sequence (0008, 1110) 	>Accession Number  (0008, 0050) 	>Requested Procedure ID (0040, 1001) 	>Requested Procedure Description (0032, 1060) 	>Requested Procedure Code Sequence  (0032, 1064) Performed Procedure Code Sequence (0040, A372) Referenced Study Component Sequence  	>Referenced SOP Class UID  (0008, 1150) 	>Referenced SOP Instance UID  (0008, 1155) Patient Name   (0010, 0010) Patient ID   (0010, 0020) Patient''s Birth Date (0010, 0030) Patient''s Sex  (0010, 0040) Referring Physicians Name (0008, 0090) Completion Flag (0040,A491) </pre> <p> <b>Verify measurements on images match measurements in report.</b> </p> <p> The Connectathon monitor should also observe logs in the <b>Image Manager</b> that demonstrate the Storage Commitment transaction.  All of the following attributes shall be verified in the Storage Commit message from the Modality: </p> <pre> Retrieve AE Title (0008, 0054) Referenced SOP Sequence (0008, 1199) 	>Reference SOP Class (0008, 1150) 	>Referenced SOP Instance UID (0008, 1155) </pre> <p> The Connectathon monitor should observe the <b>Image Display</b> and its ability to interpret/render the Evidence Documents. The Connectathon monitor should observe the original report at the Image Manger, the Acqusition Modality, the Evidence Creator, or another Image Display and spot check the Image Display/Report creator to verify the contents of the Structured Report are displayed correctly and completely. </p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (64, 1, 0, '2009-11-24 10:53:16.197', 'epoiseau', '<H3>Special Instructions</H3> The Image Manager/Archive must receive images from the Modalities registered in the CATH profile before this test can be run with the Image Display actor. <H3>Description</H3> The test verifies the ability of the Image Display and Image Manager actors for the [RAD-14] and [CARD-4] transactions. <H3>Evaluation</H3> <p><i> Evaluators and participants should note that this section contains all query keys documented in the Technical Framework.  At the North American Connectathon in Chicago, many Display vendors were surprised that these are requirements.  We are *not* failing systems this year if you do not support everything below.  However, the Connectathon Monitor will verify that you have a reasonable implementation that allows you to query the Image Manager using different parameters. </i></p> On the<b> Image Display </b>  <ul> <li>The Connectathon Monitor will ask the operator to demonstrate its support for the DICOM Study Root Q/R Information Model and Hierarchical Search. <p> It will demonstrate on its User Interface the ability to offer its user the following attributes as selection criteria (ie  these required query keys for the Image Displays SCU (RAD TF-2 Table 4.14-1). Query the Image Manager for combinations of:  </p> <p><b>STUDY LEVEL</b> Query Keys: <ul> <li>Study Date (0008,0020) <li>Study Time (0008,0030) <li>Accession Number (0008,0050)  <li>Patient Name (0010,0010) <li>Study ID (0020,0010)  <li>Study Instance UID (0020,000D) <li>Modalities in Study (0008,0061) <li>Referring Physician''s Name (0008,0090) </ul> <b>SERIES LEVEL</b> Query Keys: <ul> <li>Modality (0008,0020) <li>Series Number (0020,0011)  <li>Series Instance UID (0020,000E) <li>Requested Procedure ID (0040,1001)  <li>Scheduled Procedure Step ID (0040,0009)   <li>PPS Start Date (0040,0244)  <li>PPS Start Time (0040,0245) </ul> <b>IMAGE LEVEL </b>Query Keys: <ul> <li>Instance Number (0020,0013)  <li>SOP Instance UID (0008,0016) </ul> <li>Verify the ability to retrieve by study, by series and by image. <li>Verify that studies are fully retrieved.  (Correct rendering of the images is verified in a different test -- CATH_DISPLAY). </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (65, 1, 0, '2009-11-24 10:53:16.199', 'epoiseau', '<H3>Special Instructions</H3> <b><i>This test should be run on the first day of the Connectathon to enable Image Displays to do a follow-up test to Q/R these images and evidence objects.</b></i> <H3>Description</H3> The purpose of this test is to verify that an Image Manager can accept and store all real world vendor images and evidence objects which are available.  Q/R is tested in another test. <H3>Evaluation</H3> Verify that all images and evidence objects from all Acquisition Modality and Evidence Creator actors in the CATH profile are received at IM under test. Verify the total number of SOP instances stored and total number of studies stored. Verify that the objects are stored as full-fidelity objects (ie., no DICOM data elements are deleted). <p> If the CARDIAC CATH option is supported, Image Managers must support all of the following SOP classes (CARD-TF-2:4.2.1):  </p> <ul> <li>1.2.840.10008.5.1.4.1.1.7 Secondary Capture Image Storage  <li>1.2.840.10008.5.1.4.1.7.2 Multi-Frame Grayscale Byte Secondary Capture  <li>1.2.840.10008.5.1.4.1.7.3 Multi-Frame Grayscale Word Secondary Capture  <li>1.2.840.10008.5.1.4.1.1.6.1 Ultrasound Multi-frame Image Storage  <li>1.2.840.10008.5.1.4.1.1.3.1 Ultrasound Multi-frame Image Storage  <li>1.2.840.10008.5.1.4.1.1.9.1.2 General ECG Waveform Storage  <li>1.2.840.10008.5.1.4.1.1.9.2.1 Hemodynamic Waveform Storage  <li>1.2.840.10008.5.1.4.1.1.12.1 X-Ray Angiographic Image Storage  <li>1.2.840.10008.5.1.4.1.1.88.11 Basic Text SR  <li>1.2.840.10008.5.1.4.1.1.88.22 Enhanced SR  <li>1.2.840.10008.5.1.4.1.1.88.33 Comprehensive SR  <li>1.2.840.10008.5.1.4.1.1.88.40 Procedure Log Storage  </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (66, 1, 0, '2009-11-24 10:53:16.201', 'epoiseau', '<H3>Special Instructions</H3> Evidence Creator and Acquisition Modality actors perform ONE instance of this test.  <b>This should be done on the first day of the Connectathon.</b> <H3>Description</H3> <p> All Acquisition Modalities in the Cath Lab and EP Lab, and Evidence Creators, participating in the Cardiology profiles must store images of all  SOP classes it is capable of generating to the Connectathon CENTRAL_ARCHIVE. This will enable Image Manager and Image Display actors to access these objects for their testing.  </p> <p>You must enter a description of your study in the <em><a href=system_con_object.php?selected=create_object>Objects Information</a></em>.  Please upload there a screen capture of the object so that we can use it for comparison when your peers will render your images.</p> <b> Modalities and Evidence Creators could also find time to test directly sending their images and evidence objects to Image Manager actors.  </b> <H3>Evaluation</H3> <p>In order to validate the test, the connectathon monitor will check:</p> <ul> <li>that the objects are stored on the Central Archive,</li> <li>that there is a corresponding entry in the <em><a href=system_con_object.php?selected=create_object>Objects Information</a></em>  section of the kudu webtool, and </li> <li>that there is a screen capture of the objects uploaded in the <em><a href=system_con_object.php?selected=create_object>Objects Information</a></em> section of the kudu webtool, and</li> <li>that the printed output adequately describes the displayed image.</li> </ul> <p>Note that samples stored to the Central Archive are checked by a DICOM validator.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (67, 1, 0, '2009-11-24 10:53:16.203', 'epoiseau', '<H3>Special Instructions</H3> This test is equivalent to the Cardiology STRESS_Modality_IM_Interface and ECHO_IM_Interface Connectathon Test Cases. For systems participating in more than one workflow profile, only 3 instances across this set of tests need to be run across profiles.  <p> Use the RIS Mall to register a patient and obtain a worklist entry for the Modality.  </p> <H3>Description</H3> The Modality and Image Manager test their interfaces for these actions: <ul> <li>Simple MPPS Case <li>MPPS Abandoned Case <li>Storage of Images <li>Storage Commitment </ul> Note that the ability of the Image Manager to forward MPPS messages as a PPS Manager is not exercised in this test. <H3>Evaluation</H3> Connectathon Monitor will ask the Image Manager to show evidence that: <ul> <li>The images for patient MOD^IM are successfully stored <li>The images received from the modality contain attributes received in the modality worklist, including the Study Instance UID (0020,000D), and RP and SPS info in the Requested Attributes Seq (0040,0275). <li>Storage Commitment was successful (N-EVENT-REPORT was sent). <li>It received MPPS Discontinued from the Modality in the Abandoned case. </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (68, 1, 0, '2009-11-24 10:53:16.204', 'epoiseau', '<H3>Special Instructions</H3> <ul> <li>More than Acquisition Modality may participate in this test, eg an hemodynamic system and cath modality.   In this test, the term ''Modality'' refers to any acquisition device in the cath lab. <li>Use the RIS Mall to register a patient and create an order (Requested Procedure) for this test. <li>The Modality should be configured to send MPPS to the DSS/OF. <li>The Modality will C-STORE objects in this test, but storage to an Image Manager is not part of the evaluation.  If there is not an available Image Manager to C-STORE to, the Modality should be configured to send its objects to the Connectathon CENTRAL_ARCHIVE. </ul> <H3>Description</H3> This test assumes that at least two modalities will acquire data for a procedure: <ul> <li>Hemodynamics system (typically starts the procedure) <li>Cath modality <li>Potentially an analysis or measurement system <li>EP lab systems:  EP recording system, EP logging system, Mapping system, X-ray angiography/fluoroscopy, intercardiac echo system </ul> <p> One or more of these systems may participate in this test.  If there is only one modality available, <i><u>the DSS/OF will still assume that it will be creating SPSs for the other types of systems.</u></i> </p> <p> In this test, the Modality(ies) and DSS/OF test their interfaces for these actions: <ul> <li>Modality Worklist <li>Multi-modality procedure update by the DSS/OF (CARD TF-1:B.2 and TF-2:4.1.1) <li>The Patient Not Registered / Unscheduled Case C5 (Card TF-1:3.4.5, Rad TF-2:4.6.4.1.2.3.2 and Table A.1-2) </ul> Note that the ability of the DSS/OF to forward MPPS messages as a PPS Manager is not exercised in this test. </p> <H3>Evaluation</H3> Connectathon Monitor will ask the <b>Acquistion Modality</b> and/or <b>Hemodynamic system</b> to show evidence that:  <ul> <li>it supports Broad MWL queries.  The Modality operator should demonstrate on its user interface the ability to query by combination of SPS Start Date, Modality type, Scheduled AE title. <li>In the Unscheduled Case, the MPPS message sent by the Modality (captured on the DSS/OF) contains: <ul> <li>(0010,0010) Temporary Patient ID created by the Modality (Patient ID reconciliation is not evaluated in this test) <li>(0020,000D) Study Instance UID created by the Modality.   (See characteristics of UIDs below.)  <li>(0008, 1032) Procedure Code Sequence is empty <li>In (0040,0270) - Scheduled Step Attributes Sequence, the following attributes are empty (zero-length): <ul> <li> (0008,1110) Referenced Study Sequence <li>(0008,0050) Accession Number <li> (0032,1060) RP Description <li> (0040,1001) Requested Procedure ID  <li> (0040,0007) SPS Description <li> (0040,0008) Scheduled Procedure Code Sequence <li>(0040,0009) SPS ID </ul> </ul> </ul> <p>Connectathon Monitor will ask the <b>DSS/OF </b>to show evidence that: </p> <ul> <li>It properly supports MULTI-MODALITY PROCEDURE UPDATE.  After it received the first PPS In Progress Message it creates SPSs for each modality in the procedure.  The MWL provided to all modalities in the cath lab contain the SAME Study Instance UID.   <p> In the first Scheduled Case, it is the Study Instance UID generated by the DSS/OF. </p> In the Unscheduled Case, it is the Study Instance UID generated by the Modality whiich started the procedure. </p> <li>It creates valid DICOM Study Instance UIDs (0020,000D): <ul> <li>UIDs should not be longer than 64 chars, <li>should not contain leading zeroes in a non-zero component,  <li>should not end with a "." or a space character (no space padding for UIDs!)  <li>in general should start with "1.2", "1.3" or "2.16" (other roots are theoretically possible but very unlikely to be legal). </ul> </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (69, 1, 0, '2009-11-24 10:53:16.207', 'epoiseau', '<H3>Special Instructions</H3> This test is identical to the Radiology SWF_ORDERS Connectathon Test Case and the ECHO_ORDERS Connectathon Test Case, but uses Cath orders. Only 3 instances of this test need to be run across profiles.  <p> Use the RIS MALL as an ADT simulator to register patients for this test.  </p> <H3>Description</H3> This test verifies the ability of the Order Placer, DSS/Order Filler and Image Manager to exchange order and status information (RAD-TF-1: 3.3.3 and RAD-TF-2: 4.3.4)  - patients are registered; orders are created and cancelled at both the OP and DSS/OF.   <p> <strong>NOTE:</strong>  The following transactions are tested in other test cases and are not verified in detail here, but you could check for the proper exchange of these messages </p> <ul> <li>[RAD-1] ADT notifies OP and DSS/OF of new patient registration. <li>[RAD-12] ADT notifies OP and DSS/OF patient update or merge. </ul> <H3>Evaluation</H3> <p> On the <strong>OP</strong> user interface or database, verify that: </p> <ul> <li>Orders 18110 or 18111 are cancelled. <li>There is an order 911250 for patient SYS_NAME^ORDERS2. </ul> <p> On the <strong>DSS/OF</strong> user interface or database, verify that: </p> <ul> <li>There is no order 18110 waiting to be scheduled for patient SYS_NAME^ORDERS1. <li>There is an order 911250 for patient SYS_NAME^ORDERS2. <li>A copy of the ORR message from the OP (transaction RAD-3) has been captured, eg in [test-case-no]-orr-msg.txt.  ORC-2 should contain the Placer Order number recorded at the OP for procedure 911250 for patient SYS_NAME^ORDERS2 . </ul> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (70, 1, 0, '2009-11-24 10:53:16.209', 'epoiseau', '<H3>Special Instructions</H3> This test case is used for Full Workflow testing with as complete a complement of actors as possible.  If necessary, use the RIS Mall for ADT, OP and/or OF functionality.  Typically, this test may be run on the last day of the Connectathon, after the previous tests have been successfully completed.  It is run under the supervision of a Connectathon Monitor who checks the results of the transactions as the test is executed. <p> Ideally, there would be a hemodynamic (HD) and an angio (XA) modality available for this test; however, that will most likely not be the case. If there is no HD modality available, execute with only a single modality for a cath lab. In the real world, this is analogous to the hemo system being non-IHE compliant.  </p> In the test steps to follow, the patient first name, SYS_NAME, should be a combination of both the Image Manager and Modality systems under test, for example PACS_ABC-MOD_XYZ_XA.  </p> <H3>Description</H3> <p> This test verifies the ability of the actors in the CATH profile in the full scheduled workflow, specifically CATH Use Case C1 (CARD-TF-1: 3.4.1). This test corresponds with Radiology Scheduled Workflow Simple Case (RAD-TF-2: 4.6.4.1.2.3.1 and Table A.1-1) '' a (John Doe) Patient is registered, an Order is created and a Procedure is scheduled and performed. Finally, the Doe patient is reconciled.  <p>Modalities and Evidence Creators should send PPS messages to the DSS/OF.   There is no PPS Manager in this test. </p> <H3>Evaluation</H3> On the <strong>DSS/OF</strong>, verify: <ul> <li>There is no entry for patient Doe^SYS_NAME (it was merged with patient Merge^SYS_NAME). <li>Verify that the PPS is associated with the original Requested Procedure from the OP and provided in the MWL: <ul> <li> (0040,0001) Requesed Procedure ID </ul> </ul> <p> On the <strong>Image Manager</strong>, find the study for patient Merge^SYS_NAME.  Verify that: <ul> <li>	The images objects are successfully stored on the IM.  Check that the following fields match what was provided in the MWL: <ul> <li> (0008,0050) Accession Number  <li> (0020,000D) Study Instance UID </ul> <li>	The DSS/OF forwarded the N-SET PPS message by viewing the captured message, eg in [test-case-no]-pps-complete.txt. <li>	There are no images for patient Doe^SYS_NAME. </ul> </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (71, 1, 0, '2009-11-24 10:53:16.211', 'epoiseau', '<H3>Special Instructions</H3> This test is the same as the Radiology PIR Connectathon Case 4 test.  It only needs to be executed within one profile. <p> Use the RIS MALL as an ADT and OP simulator to register and provide an order number during this test.  <H3>Description</H3> <p> This test verifies the case where the order is placed in the department and the patient is assigned a temporary Patient ID.  Later, after the patient is registered, the DSS/OF reconciles the patient internally and sends update messages to the OP and IM.   Specifically, this is CATH Case C4 (CARD-TF-1: 3.4.4), also PIR Case 4 (RAD-TF-1: 4.4.4).  </p> <p> <strong>NOTE:</strong>  The following transactions are tested in other test cases and are not verified in detail here, but you could check for the proper exchange of these messages. </p> <ul> <li>[RAD-5] Modality Worklist <li>[CARD-2] Image Storage <li>[RAD-10] Storage Commitment <li>[CARD-1] [RAD-7]  The ability of the PPS Manager to forward MPPS messages received. </ul> <H3>Evaluation</H3> <p> On the <strong>Image Manager</strong>, verify that the objects stored for this test contain: <ul> <li>Patient ID and Patient Name (OF_SYSTEM-IM_SYSTEM^C4-DOE-REALNAME) generated at the ADT (Received in RAD-12). <li>No objects exist for patient OF-SYSTEM^DOE_IN_DEPT. <li>If there are errors, check the message captured in [test-case-no]pat-upd-case4.txt. </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (72, 1, 0, '2009-11-24 10:53:16.213', 'epoiseau', '<H3>Special Instructions</H3> Note: TWO acquisition modalities are needed to execute this test.   If only one modality is available, you should run test CATH_USE_CASE_C1. <p> This tests a room change.  Be creative in exercising the requirements in the Technical Framework: eg, if you have 2 XA modalities available to test, start the procedure in one room and obtain the remaining images in the new room.  If you have an XA and HD system, acquire the XA images in one room and obtain and store the HD data from the new room. </p> <p> This test case is used for Full Workflow testing with as complete a complement of actors in the CATH profile as possible.  If necessary, use the RIS Mall for ADT, OP and/or OF functionality.  Typically, this test may be run on the last day of the Connectathon, after the previous tests have been successfully completed.  It is run under the supervision of a Connectathon Monitor who checks the results of the transactions as the test is executed. </p> <p>PPS messages should go to the IM.  There is no PPS Manager in this test </p> <H3>Description</H3> This test verifies the transactions among the DSS/Order Filler, Acquisition Modality and Image Manager actors when the room is changed during the procedure, specifically CATH Use Case C7 (CARD-TF-1: 3.4.7); it also tests transactions for updating an unidentified patient between procedures '' CATH Use Case C6. <H3>Evaluation</H3> The Connectathon Monitor will check the results of each transaction as the test is executed.   Some specifics to check: <p>  On the <b>DSS/OF</b>, verify:  </p> <ul> <li>The status of procedure XX-40061 for patient SYS_NAME^NEWROOM is complete on the user interface or database.   Note patient''s new name. <li>A copy of the PPS Discontinued message from Modality1 has been captured, eg in [test-case-no]-pps-disc.txt. Check that the following fields match what was provided in the MWL:  <ul> <li>(0008,0050) Accession Number  <li>(0020,000D) Study Instance UID  </ul> <li>A copy of the PPS Complete message from Modality2 (transaction RAD-6) has been captured, eg in [test-case-no]-pps-disc.txt. Verify that the PPS is associated with the original Requested Procedure from the OP (RIS Mall) and provided in the MWL:  <ul> <li>(0040,0001) Requested Procedure ID  </ul> </ul> <p>On the <b>Image Manager</b>, find the study for patient SYS_NAME^NEWROOM. Verify that:  <ul> <li>The images objects from both Modality1 and Modality2 are successfully stored on the IM <b><u>in the same study with patient name of SYS_NAME^NEWROOM</b></u>. Check the first and last image in the study and verify that the values for the following elements match what was provided in the MWL:  <ul> <li>(0008,0050) Accession Number  <li>(0020,000D) Study Instance UID  </ul> </ul>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (73, 1, 0, '2009-11-24 10:53:16.215', 'epoiseau', '<H3>Special Instructions</H3> <strong>Note:</strong>  TWO acquisition modalities are needed to execute this test. <p> Use the RIS MALL as an ADT and OP simulator to register patients and create orders for this test.  </p> <H3>Description</H3> This test verifies the transactions among the DSS/Order Filler, Acquisition Modality and Image Manager when the room is changed during the procedure, specifically CATH Use Case C7 (CARD-TF-1: 3.4.7). <p> NOTE:  The following transactions are tested in other test cases and are not verified in detail here, but you could check for the proper exchange of these messages. </p> <ul> <li>[RAD-1] ADT notifies OP and DSS/OF of patient registration. <li>[RAD-2] OP notifies DSS/OF of new order. <li>[RAD-3] OF informed OP about status of orders it is filling. <li>[RAD-4] DSS/OF notifies IM of new procedure scheduled. <li>[RAD-5] Acquisition modality queries DSS/OF for worklist. <li> The ability of the PPS Manager to forward PPS messages. </ul> <H3>Evaluation</H3> <p>On the <strong>DSS/OF</strong>, verify: </p> <ul> <li>The status of procedure XX-40061 for patient SYS_NAME^ROOMCHANGE is complete on the user interface or database. <li>A copy of the PPS Discontinued message from Modality1 has been captured, eg in [test-case-no]-pps-disc.txt.  Check that the following fields match what was provided in the MWL: <ul> <li> (0008,0050) Accession Number  <li> (0020,000D) Study Instance UID </ul> <li>A copy of the PPS Complete message from Modality2 (transaction RAD-6) has been captured, eg in [test-case-no]-pps-disc.txt. Verify that the PPS is associated with the original Requested Procedure from the OP (RIS Mall) and provided in the MWL: <ul> <li> (0040,0001) Requested Procedure ID </ul> </ul> <p> On the <strong>Image Manager</strong>, find the study for patient SYS_NAME^ROOMCHANGE.  Verify that: </p> <ul> <li>The images objects from both Modality1 and Modality2 are successfully stored on the IM in the same study.  Check the first and last image in the study and verify that the values for the following elements match what was provided in the MWL: <ul> <li> (0008,0050) Accession Number  <li> (0020,000D) Study Instance UID </ul> </ul>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (74, 1, 0, '2009-11-24 10:53:16.217', 'epoiseau', '<H3>Special Instructions</H3> <p>None</p> <H3>Description</H3> <p>ADT system creates accounts and registers patients.  Order Filler creates Technical and Professional Charges. </p> <p> This test requires ADT, Order Filler and Acquisition modality systems together </p> <p>The RIS_MALL can play the role of the order placer </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (75, 1, 0, '2009-11-24 10:53:16.219', 'epoiseau', '<H3>Special Instructions</H3><p> <p>The Connectathon Monitor will assign a Modality which supports the Billing and Materials    Management Option to assist with this test.  The Modality should already have    successfully completed either the <strong>EyeCare_Modality_IM </strong>or the     <strong>EyeCare_Brief_Workflow</strong> test in the Eye Care Workflow test plan prior to    assisting with this test.  <br> </p> <p>The Modality will generate Performed Procedure Step messages containing proper codes in the    Billing Procedure Step Sequence (0040,0320).<br> </p> <p>Transactions from the ADT to the Charge Processor system are included as optional transactions    in the event an ADT is available to participate in this test.  </p> </p> <H3>Description</H3> <p>The DSS/Order Filler and Charge Processor test their interface for the Charge Posted [RAD-35]    transaction. .</p> <H3>Evaluation</H3> <p>Connectathon Monitor will ask the Charge Processor to show evidence that:</p><ul>     <li>Charge Posted transaction information was received.  This may be through observing     the User Interface; however, some information may only be observed in the database.      The following fields may be checked:</li>     <ul>      <li>Transaction Date & Procedure Date/Time should be the PPS End Date / Time (0040,0004)      (0040,0005) from the PPS message</li>      <li>Transaction Code should be from the Billing Item Sequence (0040, 0296). Note: If      the Billing Item Sequence is blank then mapping is from Procedure Code Sequence (0008, 1032)</li>      <li>Procedure Code should be from theProcedure Code Sequence (0008,1032) in the PPS msg</li>      <li>Performed by Code should be from the Performing Physician''s name (0008,1050) in      the PPS message</li>     </ul>     <li>If an ADT sytem participated, the RAD-36 transactions should be examined.<br>     </li> </ul> <p>Note that the Charge Processor''s interpretation of the information received    and subsequent billing processes are not specified in the Charge Posting profile, and are not    evaluated in this test.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (76, 1, 0, '2009-11-24 10:53:16.221', 'epoiseau', '<H3>Special Instructions</H3> <p>None</p> <H3>Description</H3> <p>The purpose of the CPI_Archive test is for all creators of GSPS objects (Modalities, Evidence Creators) to create those objects and to store those on the Central Archive. The creator of the GSPS object should also store all of the images of the study to which the GSPS object pertains.</p> <p>In order to identify the creator of the object, it would be most beneficial if the Patient Name chosen reflected the company/product of the system creating the object. 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>The GSPS objects and images sent by the Evidence Creator should be of the same genre as those normally generated by the Evidence Creator during expected clinical use.  To insure adequate testing of capabilities, the set of GSPS objects should include at least 15 elements drawn from the following GSPS capabilities:</p> <ol> <li>a selection of display area (i.e., zoom)</li> <li>a spatial transformation (rotation and/or flip)</li> <li>a discernable adjustment to the Modality LUT, if appropriate to the image object</li> <li>a discernable adjustment to the VOI LUT</li> <li>a discernable adjustment to the Presentation LUT</li> <li>a setting of display shutters (extra worthless brownie points to people who do bitmap shutters)</li> <li>text annotation boxes</li> <li>an anchor line associating a text box located in display coordinates with an anchor point in image coordinates</li> <li>graphical objects in image coordinates</li> <li>graphical objects in screen coordinates</li> <li>specification of multiple graphical layers with different suggested colors</li> <li>frame selection, if the associated image object is multi-frame</li> <li>specification of mask and contrast frames for subtraction, if appropriate for the image object</li> <li>a bitmap overlay</li> </ol> <p>As all images/GSPS objects 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.  The creator of the GSPS objects should present the Project Manager with a printed version of how the final image rendering should appear.  This should include both a list of the included 15 or more GSPS elements, and an image or description of how they should appear on the screen.  An actual printout of the image rendered correctly with the GSPS on a calibrated printer would be ideal, but barring that, any type of screen shot, or even a shot of the screen taken by a digital camera would be acceptable.</p> <p>Make sure that you upload a description of the GSPS object 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 objects.</p> <H3>Evaluation</H3> <p>In order to validate the test, the connectathon monitor will check:</p> <ul> <li>that the objects are stored on the Central Archive,</li> <li>that there is a corresponding entry in the <em><a href=system_con_object.php?selected=create_object>Objects Information</a></em>  section of the kudu webtool, and </li> <li>that there is a screen capture of the objects uploaded in the <em><a href=system_con_object.php?selected=create_object>Objects Information</a></em> section of the kudu webtool, and</li> <li>that the printed output adequately describes the displayed image.</li> </ul> <p>Note that samples stored to the Central Archive are checked by a DICOM validator.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (77, 1, 0, '2009-11-24 10:53:16.226', 'epoiseau', '<h3> Special Instructions</h3>  <p>The purpose of this test is to demonstrate the consistent rendering of images, as directed by GSPS objects, between the image display and the image creator.  We are not directly testing the Q/R of GSPS and related image objects, though a system may need to use Q/R in order to obtain those objects.  <strong>Participants may combine this test with the ARI_GSPS test; however, two evaluations will still occur (i.e., ARI_GSPS evaluates the Q/R from the IM, while CPI_C_SOFT evaluates the display consistency).</strong></p>  <p>Evidence Creator need first to perform the CPI_Archive test. </p>  <p>Please use the <em><a href=system_con_object.php target=OBJECT>Objects Information</a></em> page to find out what your peers have uploaded on the central archive </p> <h3> Description</h3> <p>An Evidence Creator sends images + GSPS objects either directly to a grouped Image Display/Image Manger, or through an Image Manager of its choice.  If the Image Display under test is not grouped with an Image Manager, then the Evidence Creator may use any available archive that supports the Q/R of images + GSPS objects for this purpose.   If the Image Display involved in the test is grouped with (i.e. belongs to the same system as) an Image Manager, then the Evidence Creator may send the GSPS and image objects directly to that Image Manager. </p>  <p>The GSPS objects and images sent by the Evidence Creator should be of the same genre as those normally generated by the Evidence Creator during expected clinical use.  To insure adequate testing of capabilities, the set of GSPS objects should include at least 15 elements drawn from the following GSPS capabilities: <ol> <li>a selection of display area (i.e., zoom)</li> <li>a spatial transformation (rotation and/or flip)</li> <li>a discernable adjustment to the Modality LUT, if appropriate to the image object</li> <li>a discernable adjustment to the VOI LUT</li> <li>a discernable adjustment to the Presentation LUT</li> <li>a setting of display shutters (extra worthless brownie points to people who do bitmap shutters)</li> <li>text annotation boxes</li> <li>an anchor line associating a text box located in display coordinates with an anchor point in image coordinates</li> <li>graphical objects in image coordinates</li> <li>graphical objects in screen coordinates</li> <li>specification of multiple graphical layers with different suggested colors</li> <li>frame selection, if the associated image object is multi-frame</li> <li>specification of mask and contrast frames for subtraction, if appropriate for the image object</li> <li>a bitmap overlay</li> </ol> </p>   <h3>Evaluation</h3>  <p>The project manager will check the consistent rendering between the 2 systems.</p> <p>Consistent rendering checking is perform by comparing the display of the snapshot stored in the <em><a href=system_con_object.php target=OBJECT>Objects Information</a></em> section of Kudu and the display on the screen of the ID actor.</p>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (78, 1, 0, '2009-11-24 10:53:16.228', 'epoiseau', '<h3> Special Instructions</h3>  <p>Please use the <em><a href=system_con_object.php target=OBJECT>Objects Information</a></em> page to find out what your peers have uploaded on the central archive </p><h3> Description</h3>  <p>The purpose of this test is to demonstrate the consistent rendering of images, as directed by GSPS objects, between the image display and the image creator.  We are not testing the Q/R of GSPS (cf ARI_GSPS test) and related image objects, though a system may need to use Q/R in order to obtain those objects.  <strong>Participants may combine this test with the ARI_GSPS test; however, two evaluations will still occur (i.e., ARI_GSPS evaluates the Q/R from the IM, while CPI_M_SOFT evaluates the display consistency).</strong></p>  <p>A Modality sends images + GSPS objects either directly to a grouped Image Display/Image Manager, or through an Image Manager of its choice.  If the Image Display under test is not grouped with an Image Manager, then the Modality may use any available archive that supports the Q/R of images + GSPS objects for this purpose.   If the Image Display involved in the test is grouped with (i.e. belongs to the same system as) an Image Manager, then the Modality may send the GSPS and image objects directly to that Image Manager. </p>  <p>The GSPS objects and images sent by the Modality should be of the same genre as those normally generated by the Modality during expected clinical use.  To insure adequate testing of capabilities, the set of GSPS objects should include example at least 15 elements drawn from the following GSPS capabilities: <ol> <li>a selection of display area (i.e., zoom)</li> <li>a spatial transformation (rotation and/or flip)</li> <li>a discernable adjustment to the Modality LUT, if appropriate to the image object</li> <li>a discernable adjustment to the VOI LUT</li> <li>a discernable adjustment to the Presentation LUT</li> <li>a setting of display shutters (extra worthless brownie points to people who do bitmap shutters)</li> <li>text annotation boxes</li> <li>an anchor line associating a text box located in display coordinates with an anchor point in image coordinates</li> <li>graphical objects in image coordinates</li> <li>graphical objects in screen coordinates</li> <li>specification of multiple graphical layers with different suggested colors</li> <li>frame selection, if the associated image object is multi-frame</li> <li>specification of mask and contrast frames for subtraction, if appropriate for the image object</li> <li>a bitmap overlay</li> </ol> </p>   <h3>Evaluation</h3>  <p>The project manager will check the consistent rendering between the Modality and the Image Display.</p>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (79, 1, 0, '2009-11-24 10:53:16.23', 'epoiseau', ' <H3>Special Instructions</H3><p> <p>None</p> <h3>Description</h3>  <p>The purpose of the CPI_Render test is to insure that Image Displays claiming to support the CPI profile can adequately interpret GSPS objects and render Image objects in accordance with the Attributes stored in the GSPS. The CPI profile requires that Image Displays support all Attributes available in a GSPS, including: <ol> <li>a selection of display area (i.e., zoom),</li> <li>spatial transformations,</li> <li>adjustments to the various LUTs (e.g., Modality, VOI, Presentation),</li> <li>display shutter settings of various types,</li> <li>graphical objects and text annotations in both image and screen coordinates,</li> <li>distinct graphical layers (e.g. color),</li> <li>frame selection (if the ID supports multi-frame image objects),</li> <li>selection of mask and contrast frames for subtraction (if the objects that the ID supports include subtraction, e.g. for angiographic image objects),</li> <li>bitmap overlays,</li> <li>etc.</li> </ol>  </p>   <p>For this test, an Image Display will be asked to render at least <strong>5 images + GSPS object</strong> from the Central Archive (Objects stored on a different archive are also accepted).  The Project Manager, not the participant,  will select which 5 image + GSPS objects will be rendered for test evaluation.  If the Project Manager has concerns about an Image Display''s capabilities to render image + GSPS object combinations, the Project Manager may ask the participant to render more than 5 images.  The Project Manager may select image + GSPS objects similar to those provided for the MESA tests, and/or may select images stored onto the Central Archive by other participants (see the CPI_Archive test)</p>  <p>In order to find out the different GSPS objects available for rendering, one shall use the <a href=system_con_object.php target=OBJECT>object information page</a></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 GPSP and associated image objects that will be available in the Central Archive to insure that their implementation can truly handle GSPS objects from multiple of vendors.  The Project Managers will announce which 5 image + GPSP objects will be used for evaluation after the first day of test, in order to give GSPS 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 objects are rendered correctly as specified in the GSPS objects, taking into account the capabilities of the Image Display (e.g. a grayscale display cannot be expected to render graphics in color). Monitors shall ask to compare the rendering of the object with the snapshots store in the object information section of Kudu.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (80, 1, 0, '2009-11-24 10:53:16.233', 'epoiseau', '<H3>Special Instructions</H3> <p>None.</p> <H3>Description</H3> <p>In this test you upload a sample prepopData XML document (CCD format) into kudu.  This sample will be examined by a connectathon monitor.</p> <p>Use data for one of the patients in test <b>CRD_prepopData_CCD_Option</b> to create prepopData that would be sent to a CRD Form Manager. <p> <p>This list contains the minimum content that must be  present your the CRD prepopData sample.  (R) indicates a required section.  (R2) indicates Required Section if data is present. (O) is optional. Additional content is acceptable, but the  document must contain the following information:</p> <li>(R) Date of Birth</li> <li>(R) Gender</li> <li>(O) Ethnicity</li> <li>(R2) Race</li> <li>(R) Active Problems, 1.3.6.1.4.1.19376.1.5.3.1.3.6</li> <li>(R2) Past Medical History, 1.3.6.1.4.1.19376.1.5.3.1.3.8/li> <li>(R2) Procedures and Interventions, 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.11</li> <li>(R2) Social History, 1.3.6.1.4.1.19376.1.5.3.1.3.16</li> <li>(R) Current Medications, 1.3.6.1.4.1.19376.1.5.3.1.3.19</li> <li>(R2) Vital Signs, 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2</li> <li>(R2) Physical Exam, 1.3.6.1.4.1.19376.1.5.3.1.1.9.15</li> <li>(R) Allergies and Other Adverse Reactions, 1.3.6.1.4.1.19376.1.5.3.1.3.13</li> <li>(R2) Coded Results, 1.3.6.1.4.1.19376.1.5.3.1.3.28</li>  <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. Do not invent codes or  import other codes. If you find that page lacking, inform the Connectathon  monitor about appropriate coded values for inclusion.</p> <p>These next steps refer to storing the document and reference information in the Kudu tool.</p> <ol> <li>You will find the page in the Kudu tool by selecting <b>Connectathon</b> and then <b>Connectathon...Objects</b>. The link to that page is <em><a href=system_con_object.php>Objects Information</a></em> </li>  <li>Enter  your Kudu system name into the description of the <em>Connectathon Images/CDAs/Objects</em>.</li>  <li>Name the document CRD_CCD_kudu.xml where <strong><em>kudu</em></strong> is your Kudu system name.</li> <li>Upload the xml file in the <em>Connectathon Images/CDAs/Objects</em> section of Kudu.</li> <li>Mark this test as ''Ready to be verified.  That will trigger a monitor to retrieve and examine your sample.</li> </ol>    <p>One Connectathon Monitor will be assigned to scrutinize CRD 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      and content that was specified in the Publish test.</p>  <p>The Connectathon Monitor will take the files offline and perform evaluation.      The monitor will document any deficiencies and ask the Form Filler 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 Form Fillers have submitted. </p> <p>The NIST Evaluation tools are found at http://xreg2.nist.gov/cda-validation/index.html.      For documents not supported by the NIST tool, use the schematron file found at IHESCHEMATRON.   </p><p>In the evaluation, the Connectathon Monitor will follow these steps:    <ol>      <li>Use Schematron test tool to see that document passes schematron tests for CRD</li>       <li>Examine the CRD prepopData by hand (possibly with style sheet) and examine for CRD specific content.              </li>     <ol> <p>These items describe the minimum content that must be  present in the CRD prepopData sample.  (R) indicates a required section.  (R2) indicates Required Section if data is present. (O) is optional. Additional content is acceptable, but the  document must contain the following information:</p> <li>(R) Date of Birth</li> <li>(R) Gender</li> <li>(O) Ethnicity</li> <li>(R2) Race</li> <li>(R) Active Problems, 1.3.6.1.4.1.19376.1.5.3.1.3.6</li> <li>(R2) Past Medical History, 1.3.6.1.4.1.19376.1.5.3.1.3.8/li> <li>(R2) Procedures and Interventions, 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.11</li> <li>(R2) Social History, 1.3.6.1.4.1.19376.1.5.3.1.3.16</li> <li>(R) Current Medications, 1.3.6.1.4.1.19376.1.5.3.1.3.19</li> <li>(R2) Vital Signs, 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2</li> <li>(R2) Physical Exam, 1.3.6.1.4.1.19376.1.5.3.1.1.9.15</li> <li>(R) Allergies and Other Adverse Reactions, 1.3.6.1.4.1.19376.1.5.3.1.3.13</li> <li>(R2) Coded Results, 1.3.6.1.4.1.19376.1.5.3.1.3.28</li>   </ol> </ol> </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (81, 1, 0, '2009-11-24 10:53:16.236', 'epoiseau', '<H3>Special Instructions</H3>   <p>CRD Form Fillers and Form Managers which support the CCD option run this test.</p>   <H3>Description</H3>  <p>This test asks Form Fillers to create pre-population data for two subjects/patients and then    verifies that this data is sent back correctly by the Form Manager in the form returned to the    Form Filler.</p>   <p>Data to be used in this test follows: </p>   <table width="1005" border="3" cellspacing="0" cellpadding="0">    <tr>     <td width="99" bgcolor="#CCCCCC">      <div align="center">       <strong>Data Element </strong>      </div>     </td>     <td width="177" bgcolor="#CCCCCC">      <div align="center">       <strong>Template ID </strong>      </div>     </td>     <td width="243" bgcolor="#CCFFCC">      <div align="center">       <strong>data for subject Miguel </strong>      </div>     </td>     <td width="2" bgcolor="#CCFFCC">''</td>     <td width="35" bgcolor="#CCFFCC">      <p align="center">       <strong>Eval:<br/> Y/N</strong>      </p>     </td>     <td width="243" bgcolor="#FFFFCC">      <div align="center">       <strong>data for subject Kendra </strong>      </div>     </td>     <td width="42" bgcolor="#FFFFCC">      <div align="center">       <strong>Eval: Y/N </strong>      </div>     </td>     <td width="142" bgcolor="#CCCCCC">      <div align="center">       <strong>Evaluator''s Comments</strong>      </div>     </td>    </tr>    <tr>     <td>Date of Birth </td>     <td>patientRole/patient/birthTime</td>     <td>19440404</td>     <td>''</td>     <td>''</td>     <td>19660606</td>     <td>''</td>     <td>''</td>    </tr>    <tr>     <td>Gender</td>     <td>      <p>patientRole/patient/<br/> administrativeGenderCode</p>     </td>     <td>M</td>     <td>''</td>     <td>''</td>     <td>F</td>     <td>''</td>     <td>''</td>    </tr>    <tr>     <td>Ethnicity</td>     <td>patientRole/patient/<br/> ethnicGroupCode</td>     <td>2149-3 (Mexican American)</td>     <td>''</td>     <td>''</td>     <td>(none)</td>     <td>''</td>     <td>''</td>    </tr>    <tr>     <td>Race</td>     <td>patientRole/patient/raceCode</td>     <td>2106-3 (White) </td>     <td>''</td>     <td>''</td>     <td>2029-7 (Asian Indian) </td>     <td>''</td>     <td>''</td>    </tr>    <tr>     <td>Active Problems </td>     <td>      <p>component/section/entry/act/<br/> entryRelationship/observation</p>     </td>     <td>      <p>Knee strain </p>     </td>     <td>''</td>     <td>''</td>     <td>      <p>Chronic Migraine Headaches </p>     </td>     <td>''</td>     <td>''</td>    </tr>    <tr>     <td>Past Medical History </td>     <td>      <p>component/section/entry/act/<br/> entryRelationship/observation</p>     </td>     <td>Patient is recovering from a salomnella infection from eating raw eggs. </td>     <td>''</td>     <td>''</td>     <td>      <p>Patient suffers from asthma. </p>      <p>Patient experiences arthritis in her left foot that was broken in the past.</p>      <p>Patient was a pack-a-day tobacco smoker for 10 years. She quit smoking in 1990. </p>     </td>     <td>''</td>     <td>''</td>    </tr>    <tr>     <td>Procedures and Interventions </td>     <td>component/section/entry/<br/> procedure</td>     <td>      <p>MRI of left knee </p>     </td>     <td>''</td>     <td>''</td>     <td>      <p>Head CT </p>     </td>     <td>''</td>     <td>''</td>    </tr>    <tr>     <td>Social History </td>     <td>component/section</td>     <td>text="Miguel is a tri-athlete <br/> who runs at least 5 miles a day." </td>     <td>''</td>     <td>''</td>     <td>text="Patient is a foster mother caring for a 3-month infant." </td>     <td>''</td>     <td>''</td>    </tr>    <tr>     <td>Current Medications </td>     <td>component/section/entry/<br/> substanceAdminstration</td>     <td>      <p>Augmentin 125 Mg Chew</p>      <p>Freq: twice/day. Start: 11-Feb-09. Status: active </p>     </td>     <td>''</td>     <td>''</td>     <td>      <p>Albuterol Sulfate 108 MCG/ACT AERS</p>      <p>Freq: 2 puffs q6hrs pm. Start: 21-Feb-09. Status: active </p>      <p>=================</p>      <p>Naproxen Sodium 550 MG TABS</p>      <p>Take one tablet by mouth every six hours as needed.</p>     </td>     <td>''</td>     <td>''</td>    </tr>    <tr>     <td>Vital Signs </td>     <td>component/section/entry/<br/> organizer/<br/> component/observation/</td>     <td>      <p>code/code=8380-6</p>      <p>code/displayName=<br/> INTRAVASCULAR SYSTOLIC</p>      <p>code/codeSystem=<br/> 2.16.840.1.113883.6.1</p>      <p>value/value=68</p>      <p>value/unit=mm[Hg]</p>      <p>===========================</p>      <p>code/code=8462-4</p>      <p>code/displayName=<br/> INTRAVASCULAR DIASTOLIC</p>      <p>code/codeSystem=<br/> 2.16.840.1.113883.6.1</p>      <p>value/value=108</p>      <p>value/unit=mm[Hg]</p>      <p>=========</p>      <p>Pulse: 82 / minute</p>      <p>Respiration: 29 / minute </p>     </td>     <td>''</td>     <td>''</td>     <td>      <p>code/code=8380-6</p>      <p>code/displayName=<br/> INTRAVASCULAR SYSTOLIC</p>      <p>code/codeSystem=<br/> 2.16.840.1.113883.6.1</p>      <p>value/value=102</p>      <p>value/unit=mm[Hg]</p>      <p>===========================</p>      <p>code/code=8462-4</p>      <p>code/displayName=<br/> INTRAVASCULAR DIASTOLIC</p>      <p>code/codeSystem=<br/> 2.16.840.1.113883.6.1</p>      <p>value/value=140</p>      <p>value/unit=mm[Hg]</p>      <p>======</p>      <p>Pulse: 86 / minute</p>      <p>Respiration: 30 / minute </p>     </td>     <td>''</td>     <td>''</td>    </tr>    <tr>     <td>Physical Exam</td>     <td>component/section</td>     <td>      <p>code/code=10210-3</p>      <p>code/displayName=<br/> GENERAL STATUS</p>      <p>code/codesSystem=<br/> 2.16.840.113883.6.1</p>      <p>text="This is a very healthy patient." </p>     </td>     <td>''</td>     <td>''</td>     <td>None</td>     <td>''</td>     <td>''</td>    </tr>    <tr>     <td>Allergies and Other Adverse Reactions </td>     <td>component/section/entry/act/<br/> entryRelationship/observation</td>     <td>      <p>Milk Products - active allergy</p>      <p>Peanuts - active allergy </p>     </td>     <td>''</td>     <td>''</td>     <td>      <p>Laytex - active allergy </p>     </td>     <td>''</td>     <td>''</td>    </tr>    <tr>     <td>Coded Results </td>     <td>''</td>     <td>''</td>     <td>''</td>     <td>''</td>     <td>''</td>     <td>''</td>     <td>''</td>    </tr>   </table> <H3>Evaluation</H3>  <Evaluation>   <p>The Connectathon Monitor will check for correct exchange of the pre-population data contained    in the test description. </p>   <p>The table in the test description contains all "R" and "R2" elements in the CCD option. The    connectathon monitor will use this table to record (Y/N) which elements were successfully    exchanged.</p>   <p>The Connectathon Monitor may ask the Form Filler to request the forms for the test patients    again in his/her presence, or to send data for an additional subject/patient and observe the    transfer real-time.</p>   <p>On the <strong>Form Filler</strong>, the Connectathon monitor will observe that a form is    returned with the data in the Test Description pre-populated on the form. The Form Filler should    be able to add additional data, or change existing fields, and then submit the completed form    back to the Form Manager.</p>    </Evaluation>');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (82, 1, 0, '2009-11-24 10:53:16.238', 'epoiseau', '<h3>Special Instructions</h3>     <p>CRD Form Fillers and Form Managers which support the CDASH option run this test.</p>  <h3>Description</h3> <p>This test asks Form Fillers to create pre-population data for two subjects/patients and then       verifies that this data is sent back correctly by the Form Manager in the form returned to the       Form Filler.</p>     <p>Data to be used in this test follows. This table contains all of the "R" and "R2" elements.       Refer to the CRD Trial Implementation Supplement Sec 5.8.4 for a definition of each Clinical       Database Variable Name. </p>     <table width="668" border="3" cellspacing="0" cellpadding="0">       <tr>         <td width="146" bgcolor="#CCCCCC">           <strong>CDASH Domain </strong>         </td>         <td width="96" bgcolor="#CCCCCC">           <strong>Clinical DB variable name </strong>         </td>         <td width="110" bgcolor="#99FFCC">           <div align="center">             <strong>Subject 1 </strong>           </div>         </td>         <td width="49" bgcolor="#99FFCC">           <div align="center">             <p>               <strong>Eval:<br/>               </strong>               <strong>Y/N</strong>             </p>           </div>         </td>         <td width="105" bgcolor="#FFFFCC">           <div align="center">             <strong>Subject 2 </strong>           </div>         </td>         <td width="49" bgcolor="#FFFFCC">           <div align="center">             <strong>Eval:<br/> Y/N</strong>           </div>         </td>         <td width="93" bgcolor="#CCCCCC">           <div align="center">             <strong>Evaluator''s Comments </strong>           </div>         </td>       </tr>       <tr>         <td>           <strong>Common Identifiers </strong>         </td>         <td>STUDYID</td>         <td>111</td>         <td>''</td>         <td>112</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>SITEID</td>         <td>Chicago09</td>         <td>''</td>         <td>Vienna09</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>SUBJID</td>         <td>SUBJ-1</td>         <td>''</td>         <td>SUBJ-2</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>           <strong>Demography</strong>         </td>         <td>BRTHRY</td>         <td>1944</td>         <td>''</td>         <td>1966</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>BRTHMO</td>         <td>04</td>         <td>''</td>         <td>06</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>BRTHDY</td>         <td>04</td>         <td>''</td>         <td>06</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>SEX</td>         <td>M</td>         <td>''</td>         <td>F</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>DMDTC</td>         <td>today''s date </td>         <td>''</td>         <td>today''s date </td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>RACE</td>         <td>2106-3 (White) </td>         <td>''</td>         <td>2029-7 (Asian Indian) </td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>           <strong>Subject Characteristics </strong>         </td>         <td>SCDTC</td>         <td>today''s date </td>         <td>''</td>         <td>today''s date </td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>           <strong>Medical History </strong>         </td>         <td>MHTERM</td>         <td>Patient is recovering from a salomnella infection from eating raw eggs. </td>         <td>''</td>         <td>           <p>Patient suffers from asthma </p>           <p>Patient experiences arthritis in her left foot that was broken in the past.</p>         </td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>MHONG</td>         <td>''</td>         <td>''</td>         <td>Arthritis is ongoing </td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>           <strong>Concomitant Medication </strong>         </td>         <td>CMTRT</td>         <td rowspan="8">           <p>Augmentin 125 Mg Chew</p>           <p>Freq: twice/day. Start: 11-Feb-09. Status: active </p>         </td>         <td>''</td>         <td rowspan="8">           <p>Albuterol Sulfate 108 MCG/ACT AERS</p>           <p>Freq: 2 puffs q6hrs pm. Start: 21-Feb-09. Status: active </p>           <p>=================</p>           <p>Naproxen Sodium 550 MG TABS</p>           <p>Take one tablet by mouth every six hours as needed.</p>         </td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>CMINDC</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>CMDOSTOT</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>CMROUTE</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>CMSTDTC</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>CMSTTM</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>CMENDTC</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>CMENTM</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>           <strong>Substance Use </strong>         </td>         <td>SUTRT</td>         <td>None</td>         <td>''</td>         <td rowspan="2">Patient was a pack-a-day tobacco smoker for 10 years. She quit smoking in           1990.</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>SUNCF</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>           <strong>Vital Signs </strong>         </td>         <td>VSDTC</td>         <td>today''s date </td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>VSTEST</td>         <td rowspan="6">           <p>code/code=8380-6</p>           <p>code/displayName=<br/> INTRAVASCULAR SYSTOLIC</p>           <p>code/codeSystem=<br/> 2.16.840.1.113883.6.1</p>           <p>value/value=68</p>           <p>value/unit=mm[Hg]</p>           <p>==========</p>           <p>code/code=8462-4</p>           <p>code/displayName=<br/> INTRAVASCULAR DIASTOLIC</p>           <p>code/codeSystem=<br/> 2.16.840.1.113883.6.1</p>           <p>value/value=108</p>           <p>value/unit=mm[Hg]</p>           <p>=========</p>           <p>Pulse: 82 / minute</p>           <p>Respiration: 29 / minute </p>         </td>         <td>''</td>         <td rowspan="6">           <p>code/code=8380-6</p>           <p>code/displayName=<br/> INTRAVASCULAR SYSTOLIC</p>           <p>code/codeSystem=<br/> 2.16.840.1.113883.6.1</p>           <p>value/value=102</p>           <p>value/unit=mm[Hg]</p>           <p>========</p>           <p>code/code=8462-4</p>           <p>code/displayName=<br/> INTRAVASCULAR DIASTOLIC</p>           <p>code/codeSystem=<br/> 2.16.840.1.113883.6.1</p>           <p>value/value=140</p>           <p>value/unit=mm[Hg]</p>           <p>======</p>           <p>Pulse: 86 / minute</p>           <p>Respiration: 30 / minute </p>         </td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>VSSTAT</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>VSORRES</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>VSORRESU</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>VSLOC</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>VSPOS</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>           <strong>Physical Exam - Traditional Approach </strong>         </td>         <td>PEDTC</td>         <td>April 1, 2008</td>         <td>''</td>         <td>December 1, 2008 </td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>           <strong>Adverse Events </strong>         </td>         <td>AETERM</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>AESER</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>AEENDTC</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>AESTTM</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>AEENDTC</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>AEENTM</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td height="22">''</td>         <td>AESEV and/or AETOXGR </td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>AEREL</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>AERELTP</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>AEACN</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>AEOUT</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>           <strong>Lab Test Results - Scenario 1: Local processing </strong>         </td>         <td>LBDTC</td>         <td>''</td>         <td>''</td>         <td rowspan="7">           <p>             <strong>Test: CBC w/ Differential ; Platelet</strong>           </p>           <p>White Blood Cell (WBC) Count:</p>           <p>Result=4.50<br/> Units=MILL/MCL<br/> Ref Range=3.8-10.8 </p>           <p>------------------</p>           <p>Hemoglobin:</p>           <p>Result=13.7<br/> Units=G/DL<br/> Ref Range=11.7-15.5 </p>         </td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBTM</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBSTAT</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBCAT LBSCAT </td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBTPT</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBFAST</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBREFID</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>           <strong>Lab Test Results - Scenario 1: Local processing</strong>         </td>         <td>LBDTC</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBTM</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBSTAT</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBCAT LBSCAT </td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBTPT</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBFAST</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBPCCND</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBTESTCD and/or LBTEST </td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBORRES</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBORRESU</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBORNRLO LBORNRHI LBSTNRC </td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBNRIND</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBCLSG</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBNAM</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBREFID</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>           <strong>Lab Test Results - Scenario 3: Central processing but CRF... </strong>         </td>         <td>LBDTC</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBTM</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBSTAT</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBCAT LBSCAT </td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBTPT</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBFAST</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBTEST</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBORRES</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBCLSG</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBNAM</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBREFID</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>           <strong>ECG Test Results - Scenario 1: Central reading... </strong>         </td>         <td>LBDTC</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>SBSTAT</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBCAT LBSCAT </td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>LBTPT</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>           <strong>ECG Test Results - Scenario 2: Local reading: ECGs... </strong>         </td>         <td>EGSTAT</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>EGDTC</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>EGTM</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>EGTPT</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>EGTESTCD and/or EGTEST </td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>EGORRES</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>EGORRESU</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>           <strong>ECG Test Results - Scenario 3: Central reading (as in Scen 1): But...</strong>         </td>         <td>EGSTAT</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>EGDTC</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>EGTM</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>EGTPT</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>EGTEST</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>EGORRESU</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>EGCLSG</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>EGORRESU</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>EGCLSG</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>EGORRES</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>EGNAM</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td colspan="7" bgcolor="#CCCCCC">           <em>             <strong>List below optional attributes that are supported, but which were not included               above. Include the CDASH domain in Column 1 and Variable Name in Column 2 </strong>           </em>         </td>       </tr>       <tr>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>       <tr>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>         <td>''</td>       </tr>     </table> <h3>Evaluation</h3>     <p>The Connectathon Monitor will check for correct exchange of the pre-population data contained       in the test description. </p>     <p>The table in the test description contains all "R" and "R2" elements in the CDASH option. The       connectathon monitor will use this table to record (Y/N) which elements were successfully       exchanged.</p>     <p>The Connectathon Monitor may ask the Form Filler to request the forms for the test       subjects/patients again in his/her presence, or to send data for an additional subject/patient       and observe the transfer real-time.</p>     <p>On the <strong>Form Filler</strong>, the Connectathon monitor will observe that a form is       returned with the data in the Test Description pre-populated on the form. The Form Filler       should be able to add additional data, or change existing fields, and then submit the       completed form back to the Form Manager.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (83, 1, 0, '2009-11-24 10:53:16.243', 'epoiseau', '<H3>Special Instructions</H3> <p>This test is designed to take place on the morning of Day 1. If you are a Time Client, you want to get this done early and stay synchronized for the remainder of the week. The secondary purpose of this test is to familiarize the Connectathon monitors and new participants with the Connectathon process.</p>  <p>Configure your system to respect the local Time Zone:  <ul>   <li>Chicago: US Central (CST or CDT during daylight savings)</li>   <li>Oxford: GMT + 1 hour</li>  </ul> </p>    <H3>Description</H3> <p>Your system is being installed in the Department of Expensive Diseases. The Department has purchased a genuine IHE CT Time Server and wants you to synchronized your clock to that time server. You are happy to oblige.</p>  <p>On the morning Day 1 of Connectathon week (between 11:00 and 12:00), locate your assigned Time Server. <b><i>For Oxford, use pool.ntp.org</b></i>.  Synchronize your clock with that server and remain synchronized with that server for the remainder of the week.</p>  <H3>Evaluation</H3> Connectathon monitor will view screen captures from each client system. Monitor is looking for 2 things:  <ol>  <li>Configured with proper Time Server</li>  <li>Time synchronized within 1 second of time on Internet web resource. If this is not within 1 second, you have done something wrong.</li>  <li>Failure to change to the local time zone is a test failure.</li> </ol> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (84, 1, 0, '2009-11-24 10:53:16.245', 'epoiseau', '<H3>Special Instructions</H3> <p>Time Servers need to complete this by Day 1 at 11:05. Your Time Clients will start to syncrhonize with you at that time.</p> <p>Configure your system to respect the local Time Zone:  <ul>   <li>Chicago: US Central (CST or CDT during daylight savings)</li>   <li>Oxford: GMT + 1 hour</li>  </ul> </p>   <H3>Description</H3> <p>IHE-enabled equipment is being installed in the Department of Expensive Diseases. Your Time Server has been selected to serve as the Time Server for the entire department.</p>  <p>You know there must be other time servers in the enterprise, but you are unable to locate anyone who is able to help, and startup day is Monday. You decide the best decision is to provide reliable time by synchronizing with other servers on the Internet. You are directed to http://www.pool.ntp.org to find a system for synchronization. You are delighted to find such a resource.</p>  <ol> <li> Read the information at www.pool.ntp.org </li> <li>Synchronize your Time Server with the pool.</li> <li>Be prepared to have other systems synchronize with you</li> </ol>  <H3>Evaluation</H3> <p>Connectathon monitor will examine screen capture or real time display. The screen capture should have enough resolution to show proper clock synchronization. The Time Server should be synchronized to within 1 second of the external source (assuming reasonable network latency).</p>  <p>The system should also be set to the local time zone. Failure to change to the local time zone is a test failure.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (85, 1, 0, '2009-11-24 10:53:16.247', 'epoiseau', '<p>The CT_ServerSet defines the time on a Time Server. In some environments, the Time Server would be synchronized to an external clock. At the Connectathon, the Time Server will be synchronized to a digital watch worn by one Project Manager.</p>  <p>Each Time Server will synchronize to the digital time of the Project Manager plus some small offset (15 seconds, 30 seconds, 1 minute). This will allow the Project Manager to see times on the client systems and know the proper server. For evaluation, the Project Manager can compare the system time on the server to the PM watch.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (86, 1, 0, '2009-11-24 10:53:16.25', 'epoiseau', '<H3>Description</H3> <p>This isn''t really a ''test''.... this contains common instructions for all content creators...</p> <p>Patients have been pre-created for you in RIS Mall.  Use these demographics when you create your document.  You should consult the RIS mall demographics spreadsheet in kudu and use the patient whose patient last name matches your kudu system name.</p> <p>http://ihewiki.wustl.edu/wiki/images/8/8d/Ris-mall-demographics-20081222.xls</p> <H3>Evaluation</H3> There is no monitor evaluation for this test.');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (87, 1, 0, '2009-11-24 10:53:16.251', 'epoiseau', '<H3>Reserved for 2010 or later</H3>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (88, 1, 0, '2009-11-24 10:53:16.253', 'epoiseau', '<H3>Special Instructions</H3> <H3>TEMPORARY Instruction - ignore reference to DOFs, and if you are a DOF see Manny</H3>  <p>This test applies to sending and receiving systems that transmit and receive infrequent or aperiodic data. Examples include infusion pumps which send information when an event occurs, a vital signs monitor that sends aggregated data on command, and NIBP devices or NIBP channels in a monitor. While an NIBP monitor may be scheduled to make measurements periodically, the intervals are too long for testing in a Connectathon. These systems conduct the test for infrequent data by triggering an event or taking a reading. </p>  <p>If the sending system sends both periodic and aperiodic data, or the receiving system receives both, it is NOT necessary to perform this test unless requested to assist another system. The DEC_One_to_One_Communication_Periodic_Data test is sufficient. </p>  <p>This test applies to these partner systems: </p> <ul> <li>DOR and DOC</li>  <li>DOF and DOC</li> <p>         - The DOC will query for all or a convenient group of available data</p> <li>DOR and a standalone DOF where the input of the DOF acts like a DOC</li>         <p>         - This should be combined into DOR, DOF and DOC testing</p> </ul>  <p>Developers are responsible for coordinating with their partners in advance of the Connectathon to assure that they will have the required number of partner systems that support the same physiologic or other parameters, with consistent coding. For this reason, PCD recommends (and will shortly require) that parameters be coded as defined by the Rosetta Terminology Mapping project. Consult the project manager to determine if this requirement applies. </p>  <p>The DOR and DOC conduct this test for all system types they support that provide this type of data, for example: </p> <ul> <li>NIBP monitors or a NIBP channels in another device such as a bedside monitor</li> <li>Infusion pumps or beds where data is sent in response to an event (e.g., starting an infusion, changing the elevation of the bed) </li> </ul>  <p>If, for example, a system supports an NIBP module in a bedside monitor and an infusion pump, messages will contain parameters for the NIBP parameters within the bedside monitor and for the infusion pump. </p>  <p>Systems will send and receive parameters for at least two patients. Patient demographics are defined consistent with instructions on the PCD_Patient_Demographics test page. If your system does not support multiple patients, you need to make this known to your test partners and the project manager. </p>  <u> Related Tests</u>  <p>Developers may combine this test with: </p> <ul> <li>DEC_DOR_With_PIB (PAM and/or PDQ in the Patient Identity Binding (PIB) option) </li> </ul>  <p>To obtain credit for these additional tests, include the data and steps consistent with that additional test. </p>  <p>Developers may wish to follow this test with: </p>  <ul> <li>DEC_Multiple_DORs</li> </ul>  <H3>Description</H3> <p>Send a series of messages to the receiving system. Messages include multiple physiologic and/or operational parameters as appropriate for the devices, systems and parameters supported. </p>  <p>Send sufficient data for at least two patients to document successful transmission and receipt of the data. Within the group of partners, systems should test all system types they support (e.g., NIBP, infusion pumps, beds, and, other devices that send aperiodic or infrequent data). Each message will contain reasonable values for at least four parameters for each system type, assuming that at least four parameters are supported (e.g., four or more for each patient and device type, such as drug dose, flow rate, volume to be infused, volume remaining for each infusion pump, and systolic, diastolic, mean for NIBP). If the DOR supports both validated and unvalidated data, this test is performed with unvalidated data and then with a sample of validated data. Each message may include any number of additional parameters. </p>  <p>Parameter values should be realistic for a patient in an ICU, emergency room or step down unit. </p>  <p>Parameter data obtained for each patient should be as close as in time to data for other patients as is convenient. </p> <p>Parameters should be sent from actual devices (preferred), simulators or, if necessary from parameter tables provided by the Project Manager (least desirable). </p>  <u>Patient Identification</u> <p>Refer to the PCD_Patient_Demographics table and select two appropriate patients. </p>  <H3>Evaluation</H3> <p>Project manager or monitor will observe the displays provided by the sending and receiving system(s). The patients'' names and/or medical record numbers (MRNs), physiologic and other parameters, their measurement values, and the time of parameter measurement/acquisition will be compared. The type of display/documentation by the receiving system is not constrained, it need only be clinically useful. </p>  <p>NOTE: If other tests are conducted with this test, they will evaluated as described for those tests and the evaluation will be recorded for those tests. </p>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (89, 1, 0, '2009-11-24 10:53:16.255', 'epoiseau', '<H3>Special Instructions</H3> <p>This test addresses the ability of a DOF to function and identify a patient when the PIB option (using PAM and/or PDQ) fails to provide patient demographic information for a patient. The DOF provides a secondary way to identify the patient and link that identification with the patient''s physiologic data.  </p>  <p> If the DOF is a standalone system, this test is appropriate. If the DOF is part of a DOR/DOF system, it is necessary to test only the DOR version of this test (DEC PIB Unsuccessful Identification). A Standalone DOF is a device/system that is not part of the device/system that contains the DOR, and that relies upon a separate DOR for patient data. </p> <H4>A standalone DOF must find a DOR to assist with this test.  </H4> <p>If both PAM and PDQ options in PIB are supported, this will be accomplished by first attempting to obtain identification with PAM, and then with PDQ. That may be a manual or automatic attempt. </p>  <p><u>Related Tests: </u> Developers may efficiently integrate this test with DEC_DOF_With_PIB_Option and/or the appropriate one to one test: </p> <ul> <li>DEC_One_to_One_Communication_Periodic_Data</li> <li>DEC_One_to_One_Communication_Infrequent_Data  (data such as infusion pumps, NIBP devices or channels and beds) </li> </li> </ul>   <p>NOTE: While these test names include DOR and DOC, they apply to DOFs as well. </p>   <H3>Description</H3> <p>Conduct the appropriate one-to-one test and the DEC_DOF_With_PIB_Option test before proceeding. </p>  <p>The patient sought has the name Peter Rabbit. This patient''s demographics will not be sent in PAM messages, nor will it be in the ADT system''s database. </p>  <p>For PAM, this patient won''t be in the DOR''s database. For PDQ, query all as appropriate: </p> <ul> <li>Query by name. </li> <li>Query with location SICU room 1, bed 1. </li> <li>Query with MRN 1234. </li> </ul>   <p>When the attempt to identify the patient fails, the DOR may use any method it supports to provide sufficient patient identification to send three messages (or only one if the DOR or DOF supports data from devices sending only infrequent data). For example, if a hospital assigns temporary patient identification using the hospital name and a number (e.g., hospital name_sequential number), the DOR could use as temporary MRN: Hospital_DOR Name n, where Hospital is the facility identifier, DOR Name is the manufacturer''s name or DOR''s identification, followed by the number 1. </p>  <p>The user selects or validates the patient identification obtained and the DOR or DOF incorporates the patient identity into the messages transmitted to the DOC or DOF. </p>  <p>Sending systems will send at least three messages for each patient with reasonable values for four parameters assuming the patient is in an ICU or OR.  </p> <ul> <li>If the system only supports infrequent data (e.g., Vital Signs Monitor (VSM) or Non-Invasive Blood Pressure (NIBP) data then it will send two messages for at least two patients, with some change in parameter values in the second set of messages for each patient. </li> <li>If the system provides both periodic and infrequent data, there is no need to send the infrequent data. </li> <li>If the DOR supports both validated and unvalidated data, this test is performed with unvalidated data. </li> </ul>   <p>The sequence of messages is not important. </p>  <p>Parameter values should be realistic for a patient in a cardiac ICU bed or on an OR table. </p>  <p>Parameters should be sent from actual devices (preferred), simulators or, if necessary from parameter tables provided by the Project Manager (least desirable). </p>  <u>Patient Demographics</u> <p>Refer to the PCD_Patient_Demographics table and select two appropriate patients. </p>  <p>Developers are responsible for coordinating with their partners in advance of the Connectathon to assure that they will have the required number of partner systems that support the same physiologic or other parameters, with consistent coding. </p>  <H3>Evaluation</H3> <p>Project manager or monitor will observe the displays provided by the sending and receiving system(s). The patients'' names and/or medical record numbers (MRNs), physiologic and other parameters, their measurement values, and the time of parameter measurement/acquisition will be compared. The type of display/documentation by the receiving system is not constrained, it need only be clinically useful. </p>  <p>NOTE: If other tests are conducted with this test, they will evaluated as described for those tests and the evaluation will be recorded for those tests. </p>     <p>For PAM, this patient won''t be in the DOR''s database. For PDQ, query all as appropriate: </p> <ul> <li>Query by name. </li> <li>Query with location SICU room 1, bed 1. </li> <li>Query with MRN 1234. </li> </ul>   <p>When the attempt to identify the patient fails, the DOR may use any method it supports to provide sufficient patient identification to send three messages (or only one if the DOR or DOF supports data from devices sending only infrequent data). For example, if a hospital assigns temporary patient identification using the hospital name and a number (e.g., hospital name_sequential number), the DOR could use as temporary MRN: Hospital_DOR Name n, where Hospital is the facility identifier, DOR Name is the manufacturer''s name or DOR''s identification, followed by the number 1. </p>  <p>The user selects or validates the patient identification obtained and the DOR or DOF incorporates the patient identity into the messages transmitted to the DOC or DOF. </p>  <p>Sending systems will send at least three messages for each patient with reasonable values for four parameters assuming the patient is in an ICU or OR.  </p> <ul> <li>If the system only supports infrequent data (e.g., Vital Signs Monitor (VSM) or Non-Invasive Blood Pressure (NIBP) data then it will send two messages for at least two patients, with some change in parameter values in the second set of messages for each patient. </li> <li>If the system provides both periodic and infrequent data, there is no need to send the infrequent data. </li> <li>If the DOR supports both validated and unvalidated data, this test is performed with unvalidated data. </li> </ul>   <p>The sequence of messages is not important. </p>  <p>Parameter values should be realistic for a patient in a cardiac ICU bed or on an OR table. </p>  <p>Parameters should be sent from actual devices (preferred), simulators or, if necessary from parameter tables provided by the Project Manager (least desirable). </p>  <u>Patient Demographics</u> <p>Refer to the PCD_Patient_Demographics table and select two appropriate patients. </p>  <p>Developers are responsible for coordinating with their partners in advance of the Connectathon to assure that they will have the required number of partner systems that support the same physiologic or other parameters, with consistent coding. </p>  <H3>Evaluation</H3> <p>Project manager or monitor will observe the displays provided by the sending and receiving system(s). The patients'' names and/or medical record numbers (MRNs), physiologic and other parameters, their measurement values, and the time of parameter measurement/acquisition will be compared. The type of display/documentation by the receiving system is not constrained, it need only be clinically useful. </p>  <p>NOTE: If other tests are conducted with this test, they will evaluated as described for those tests and the evaluation will be recorded for those tests. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (90, 1, 0, '2009-11-24 10:53:16.26', 'epoiseau', '<h3>Special Instructions</h3> <p>DEC_Infusion_Pump is defined in the context of DOR/DOC pairs where the DOR is an Infusion Pump. If your DOR is not an Infusion Pump, do not perform this test.</p>  <h3>Description</h3> <p>DORs will send messages with reasonable physiologic values for supported parameters. Each message shall contain the required number of parameters that the receiving DOC can process and display or document, and may send any number of additional parameters. DORs are responsible for coordinating with their DOC partners in advance of the Connectathon to assure that the DOCs are able to receive at least the minimum three parameters required for a given test. Parameter values should be realistic for a patient in a cardiac ICU bed or on an OR table.</p>  <p>At least four parameters will be be sent for each patient; at least three of which can be processed by the receiving DOC. Minimum parameters are selected from this list:</p>  <table>  <tr><th>Parameter</th><th>Observation Sub-ID</th><th>Label</th><th>Units (UCUM)</th></tr>  <tr><td>MDC_ATTR_PT_WEIGHT</td><td>w.0.0.2</td><td>Patient Weight</td><td>kg</td></tr>  <tr><td>MDC_PUMP_MODE</td><td>w.1.1.101</td><td>Pump Mode</td><td>n/a</td></tr>  <tr><td>MDC_PUMP_STAT</td><td>w.1.1.102</td><td>Pump Status</td><td>n/a</td></tr>  <tr><td>MDC_FLOW_FLUID_PUMP</td><td>w.1.1.103</td><td>Total Rate</td><td>mL/h</td></tr>  <tr><td>MDC_FLOW_FLUID_PUMP</td><td>w.1.2.201</td><td>Primary Channel Rate</td><td>mL/h</td></tr>  <tr><td>MDC_FLOW_FLUID_PUMP</td><td>w.1.3.301</td><td>Secondary Channel Rate</td><td>mL/h</td></tr>  <tr><td>MDC_VOL_FLUID_TBI_REMAIN</td><td>w.1.2.202</td><td>Primary Channel VTBI</td><td>mL</td></tr>  <tr><td>MDC_VOL_FLUID_TBI_REMAIN</td><td>w.1.3.302</td><td>Secondary Channel VTBI</td><td>mL</td></tr>  <tr><td>MDC_TIME_PD_REMAIN</td><td>w.1.2.203</td><td>Primary Channel Time Remaining</td><td>min</td></tr>  <tr><td>MDC_TIME_PD_REMAIN</td><td>w.1.3.303</td><td>Secondary Channel Time Remaining</td><td>min</td></tr>  <tr><td>MDC_DRUG_NAME_TYPE</td><td>w.1.2.204</td><td>Primary Channel Drug Name</td><td>n/a</td></tr>  <tr><td>MDC_DRUG_NAME_TYPE</td><td>w.1.3.304</td><td>Secondary Channel Drug Name</td><td>n/a</td></tr>  <tr><td>MDC_CONC_DRUG</td><td>w.1.2.205</td><td>Primary Channel Concentration</td><td>mg/mL</td></tr>  <tr><td>MDC_RATE_DOSE</td><td>w.1.2.206</td><td>Primary Channel Dosage</td><td>ug/kg/min</td></tr> </table>  <h3>Evaluation</h3> <p>Project manager or monitor will observe the displays provided by the DOR and partner DOC. The physiologic parameters and their measurement values, including the time of parameter measurement will be compared. The type of display/documentation by the DOC is not constrained, it need only be clinically useful.</p>  <p>If the minimum number of parameters, measurements and time of measurement sent by the DOR matches those received by the DOC that will indicate the step in the test has been successful. NOTE: At least one message sent by the DOR for both patients will not have been received by the DOC (Communication Link Interrupted And Resumed) and the time recorded by the DOR for the interruption will be compared to the missing data point(s). Note also that the data must match the patient.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (91, 1, 0, '2009-11-24 10:53:16.263', 'epoiseau', '<H3>Special Instructions</H3> <p>This applies to DOR, DOF and DOC systems. </p> <p>This test is defined in the context of sending and receiving systems. </p> <p>The DEC_One_to_One_Communication test should be successfully completed before attempting this test. </p> <p>If the DOR and/or DOF send messages for continuous data: </p> <p>This is a multi-part test: During the test, a sending system will successfully send at least two messages for two patients, then interrupt the connection to the network, and then restore the connection and send at least two more messages for each patient. The interruption will be at least long enough to fail to transmit one message for each patient to the receiving system. The sending system will manually note the time the connection was interrupted and the time it was restored for later comparison with the transmitted and received data. The receiving system will note whether the sending system recognized that the first set of messages was not received and sent them again. </p> <p>If the DOR and/or DOF send messages ONLY for discontinuous data (e.g., a vital signs monitor): </p> <p>Sending systems that also provide continuous data do not address the following requirements for discontinuous data. </p> <p>Send data for two or more patients (a) before, (b) during, and (c) following the interruption. For these three communications, adjust at least one parameter value before sending the (b) and (c) messages (e.g., vary heart rate from 60 to 70 to 80). </p> <p>A system with a DOF may be required to perform this test more than once: </p> <p>If the DOR and/or DOF send messages for discontinuous data (e.g., a vital signs monitor): </p> <p>Send data for two or more patients (a) before, (b) during, and (c) following the interruption. For these three communications, adjust at least one parameter value before sending the (b) and (c) messages (e.g., vary heart rate from 60 to 70 to 80). </p> <p>A system with a DOF may be required to perform this test more than once: </p> <ul>  <li>Interrupted Communication between the Reporter and the Consumer or between the Reporter and a Standalone Filter</li> <p>       - DOR and DOC participate. </p> <p>       - DOR and standalone DOF participate '' this tests the input side of a standalone DOF that behaves as a DOC. </p> <li>Interrupted Communication between the Filter and the Consumer</li> <p>       - DOF and DOC implementing the SPD (PCD-02) option participate. This test is required of a DOF when the DOR and DOF are incorporated in the same system. </p> <p>       - DOF and DOC implementing the SPD (PCD-02) option participate. This test is required of a standalone DOF when the DOF is independent of a DOR. </p> </ul>  <p>NOTE: Developers of sending systems are responsible for coordinating with their partners in advance of the Connectathon to assure that the receiving systems. Parameter values should be realistic for a patient in a cardiac ICU bed or on an OR table. </p> <H3>Description</H3> <p>Conduct DEC_One_to_One_Communication before proceeding. </p> <p>The data source will send messages before, during and after each step of this test. The steps are: </p> <ul> <li>The DOC is receives messages from the DOR for two patients (see below). The messages contain at least three valid parameters for each patient. </li> <li>The DOR (or DOF on the output side) then interrupts its connection to the network, and then restores the connection. The interruption will be at least long enough to fail to transmit one message for each patient to the DOC. The sending system will manually note the time the connection was interrupted and restored for later comparison with the transmitted and received data. </li> <li>If a DOF is participating, the DOC will select a filter that provides data for at least three parameters for each of the two patients. </li> </ul>  <p>NOTE: Each DOR and each DOF needs to conduct this test only once. </p> <u>Patient Identification</u> <p>Refer to the PCD_Patient_Demographics table and select two appropriate patients. </p> <H3>Evaluation</H3> <p>Project manager or monitor will observe the displays provided by the DOR and partner DOC. The physiologic parameters and their measurement values, including the time of parameter measurement will be compared. The type of display/documentation by the DOC is not constrained, it need only be clinically useful. </p> <p>Success: Transmission and receipt of the minimum number of parameters, measurements and time of measurement sent by the sending system, matching those received by the receiving system before and after the interruption and restoration of communication, without a system failure. In particular, the systems must be able to attribute data to the correct patient during the entire test. If the sending system stores data that failed to reach the receiving system and sends it later, this should be called to the monitor''s attention. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (92, 1, 0, '2009-11-24 10:53:16.266', 'epoiseau', '<H3>Special Instructions</H3><p> <p>DEC_Interrupted_Communication_RC, DEC_Interrupted_Communication_FC and    DEC_Interrupted_Communication_RFC are defined in the context of sending and receiving systems,    with the exception of DORs or DOFs which only send a single message or intermittent messages,    rather than a series of messages (e.g., a vital signs monitor DOR as contrasted with a bedside    monitor DOR). </p> <p>The DEC_One_to_One_Communication test should be conducted successfully before attempting this    test.</p> <p> This is a two part test: During the test, a sending system will successfully send at least two    messages for two patients, then interrupt the connection to the network, and then restore the    connection. The interruption will be at least long enough to fail to transmit one message to the    DOC. The sending system will manually note the time the connection was interrupted and restored    for later comparison with the transmitted and received data.</p> <p> Similarly, but not simultaneously, a receiving system that successfully receives at least two    messages for two patients, will interrupt its connection to the network, and then restore the    connection. The interruption will be at least long enough to fail to receive one message. The    receiving system will manually note the time the connection was interrupted and restored for    later comparison with the transmitted and received data.</p> <p> There are three variations of this test; be sure you select the right one(s):</p> <ul>     <li>DEC_Interrupted_Communication_RC</li>     <ul>      <li>DOR and DOC participate. This test is required of DOF systems where the DOR and DOF are      incorporated in the same system.</li>     </ul>         <li>DEC_Interrupted_Communication_FC</li>     <ul>      <li>DOF and DOC implementing the SPD (PCD-02) option participate. This test is required of DOF      systems where the DOR and DOF are incorporated in the same system.</li>     </ul>         <li>DEC_Interrupted_Communication_RFC</li> </ul> <p>This test is required of standalone DOF systems where input to the DOF requires the DOF to act    as a DOC, and needs a DOR as partner; the DOF has previously succeeded in testing as a DOC with a    DOR to assure it can receive PCD-01 messages.</p> <p> NOTE: Test names are the same for all systems. They play partner roles. Developers of sending    systems are responsible for coordinating with their partners <em>in advance of the     Connectathon</em> to assure that the receiving systems. Parameter values should be realistic for    a patient in a cardiac ICU bed or on an OR table. </p> </p><H3>Description</H3><p>Conduct  DEC_One_to_One_Communication and DEC_Interrupted_Communication_RC before proceeding.</p><p>  The data source  will send messages continuously before and during each step of this test. The  steps are:</p><ul>     <li>The  DOC subscribes to physiologic data from the two patients in the table below and  terminates any other subscriptions it is receiving.</li>     <li>The  DOC is receiving messages from the DOF for two patients (see below). The  messages contain at least three valid parameters for each patient.</li>     <li>The  DOF system interrupts its connection to the DOC on the network for at least one  message for each patient, and then restores the connection. The interruption  will be at least long enough to fail to receive one message. The receiving  system will manually note the time the connection was interrupted and restored  for later comparison with the transmitted and received data.</li>     <li>DOC  terminates the subscriptions.</li> </ul><p>NOTE: This test  need be conducted only one time, with a single DOC partner.</p><p></p><p>PATIENT IDENTIFICATION:</p><p>For systems NOT using PAM or PDQ to obtain patient demographics, the patients for this test in    January 2008 are given below. Additional patients can be created using the same pattern.</p><table border="1" cellspacing="0" cellpadding="0">     <tr>      <td width="133" valign="top">       <p align="center">        <strong>System</strong>       </p>      </td>     <td width="91" valign="top">       <p align="center">        <strong>MRD</strong>       </p>      </td>     <td width="61" valign="top">       <p align="center">        <strong>First Name</strong>       </p>      </td>     <td width="67" valign="top">       <p align="center">        <strong>Last Name</strong>       </p>      </td>     <td width="127" valign="top">       <p align="center">        <strong>Location</strong>       </p>      </td>     <td width="79" valign="top">       <p align="center">        <strong>Mother&rsquo;s Maiden Name</strong>       </p>      </td>     <td width="73" valign="top">       <p align="center">        <strong>DOB</strong>       </p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; B Braun</p>      </td>     <td width="91" valign="top">       <p>BB2008001</p>      </td>     <td width="61" valign="top">       <p>Albert</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU - 31-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/61</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; B Braun</p>      </td>     <td width="91" valign="top">       <p>BB2008002</p>      </td>     <td width="61" valign="top">       <p>Charles</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/61</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Draeger (reporter)</p>      </td>     <td width="91" valign="top">       <p>DR2008001</p>      </td>     <td width="61" valign="top">       <p>Amy</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 32-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/62</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Draeger (reporter)</p>      </td>     <td width="91" valign="top">       <p>DR2008002</p>      </td>     <td width="61" valign="top">       <p>Carrie</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/62</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; GE (reporter)</p>      </td>     <td width="91" valign="top">       <p>GE2008001</p>      </td>     <td width="61" valign="top">       <p>Allen</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 33-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/63</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; GE (reporter)</p>      </td>     <td width="91" valign="top">       <p>GE2008002</p>      </td>     <td width="61" valign="top">       <p>Corey</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/63</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Philips (reporter)</p>      </td>     <td width="91" valign="top">       <p>PH2008001</p>      </td>     <td width="61" valign="top">       <p>Adrian</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 34-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/64</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Philips (reporter)</p>      </td>     <td width="91" valign="top">       <p>PH2008002</p>      </td>     <td width="61" valign="top">       <p>Connie</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/64</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Spacelabs </p>      </td>     <td width="91" valign="top">       <p>SP2008001</p>      </td>     <td width="61" valign="top">       <p>Arthur</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 35-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/65</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Spacelabs </p>      </td>     <td width="91" valign="top">       <p>SP2008002</p>      </td>     <td width="61" valign="top">       <p>Clark</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/65</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Welch Allyn</p>      </td>     <td width="91" valign="top">       <p>WA2008001</p>      </td>     <td width="61" valign="top">       <p>Andrea</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 36-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/66</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Welch Allyn</p>      </td>     <td width="91" valign="top">       <p>WA2008002</p>      </td>     <td width="61" valign="top">       <p>Camille</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/66</p>      </td>     </tr> </table><H3>Evaluation</H3><p>Project manager or monitor will observe the displays provided by the DOF and partner DOC. The physiologic parameters and their measurement values, including the time of parameter measurement will be compared. The type of display/documentation by the DOC is not constrained, it need only be clinically useful.</p><p>Success: If the patient, the minimum number of parameters, measurements and time of measurement sent by the sending system matches those received by the receiving system before and after the interruption and restoration of communication that will indicate the step in the test has been successful. In particular, the systems must be able to attribute data to the correct patient during the entire test. If the sending system stores data that failed to reach the receiving system and sends it later, this should be called to the monitor&rsquo;s attention.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (93, 1, 0, '2009-11-24 10:53:16.269', 'epoiseau', '<H3>Special Instructions</H3><p> <p>DEC_Interrupted_Communication_RC,  DEC_Interrupted_Communication_FC  and DEC_Interrupted_Communication_RFC  are defined in the context of sending and receiving systems, with the exception  of DORs or DOFs which only send a single message or intermittent messages,  rather than a series of messages (e.g., a vital signs monitor DOR as contrasted  with a bedside monitor DOR). </p> <p>The DEC_One_to_One_Communication  test should be conducted successfully before attempting this test.</p> <p> This is a two part  test: During the test, a sending system will successfully send at least two  messages for two patients, then interrupt the connection to the network, and  then restore the connection. The interruption will be at least long enough to  fail to transmit one message to the DOC. The sending system will manually note  the time the connection was interrupted and restored for later comparison with  the transmitted and received data.</p> <p>  Similarly, but not  simultaneously, a receiving system that successfully receives at least two  messages for two patients, will interrupt its connection to the network, and  then restore the connection. The interruption will be at least long enough to fail  to receive one message. The receiving system will manually note the time the  connection was interrupted and restored for later comparison with the  transmitted and received data.</p> <p>  There are three  variations of this test; be sure you select the right one(s):</p> <ul>     <li>DEC_Interrupted_Communication_RC</li>     <ul>      <li>DOR and DOC participate. This test is required of  DOF systems where the DOR and DOF are incorporated in the same system.</li>     </ul>     <li>DEC_Interrupted_Communication_FC</li>     <ul>      <li>DOF and DOC implementing  the SPD (PCD-02) option participate. This test is required of  DOF systems where the DOR and DOF are incorporated in the same system.</li>     </ul>     <li>DEC_Interrupted_Communication_RFC</li> </ul> <p>This test is required of standalone DOF systems  where input to the DOF requires the DOF to act as a DOC, and needs a DOR as  partner; the DOF has previously succeeded in testing as a DOC with a DOR to  assure it can receive PCD-01 messages.</p> <p>  NOTE: Test names  are the same for all systems. They play partner roles. Developers of sending  systems are responsible for coordinating with their partners <em>in advance of  the Connectathon</em> to assure that the receiving systems. Parameter values  should be realistic for a patient in a cardiac ICU bed or on an OR table. </p> </p><H3>Description</H3><p>Conduct  DEC_One_to_One_Communication before proceeding.</p><p>  The data source  will send messages continuously before and during each step of this test. The  steps are:</p><ul>     <li>The  DOC is receiving messages from the DOR for two patients (see below). The  messages contain at least three valid parameters for each patient.</li>     <li>The  DOR then interrupts its connection to the network, and then restores the  connection. The interruption will be at least long enough to fail to transmit  one message to the DOC. The sending system will manually note the time the  connection was interrupted and restored for later comparison with the  transmitted and received data.</li>     <li>After  restoring communication and receiving at least two messages for the two  patients, the receiving DOC system will interrupt its connection to the network  for at least one message for each patient, and then restore the connection. The  interruption will be at least long enough to fail to receive one message. The  receiving system will manually note the time the connection was interrupted and  restored for later comparison with the transmitted and received data.</li> </ul><p>NOTE: This test  need be conducted only one time, with a single partner.</p><p></p><p>PATIENT IDENTIFICATION:</p><p>For systems NOT using PAM or PDQ to obtain patient demographics, the patients for this test in    January 2008 are given below. Additional patients can be created using the same pattern.</p><table border="1" cellspacing="0" cellpadding="0">     <tr>      <td width="133" valign="top">       <p align="center">        <strong>System</strong>       </p>      </td>     <td width="91" valign="top">       <p align="center">        <strong>MRD</strong>       </p>      </td>     <td width="61" valign="top">       <p align="center">        <strong>First Name</strong>       </p>      </td>     <td width="67" valign="top">       <p align="center">        <strong>Last Name</strong>       </p>      </td>     <td width="127" valign="top">       <p align="center">        <strong>Location</strong>       </p>      </td>     <td width="79" valign="top">       <p align="center">        <strong>Mother&rsquo;s Maiden Name</strong>       </p>      </td>     <td width="73" valign="top">       <p align="center">        <strong>DOB</strong>       </p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; B Braun</p>      </td>     <td width="91" valign="top">       <p>BB2008001</p>      </td>     <td width="61" valign="top">       <p>Albert</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU - 31-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/61</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; B Braun</p>      </td>     <td width="91" valign="top">       <p>BB2008002</p>      </td>     <td width="61" valign="top">       <p>Charles</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/61</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Draeger (reporter)</p>      </td>     <td width="91" valign="top">       <p>DR2008001</p>      </td>     <td width="61" valign="top">       <p>Amy</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 32-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/62</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Draeger (reporter)</p>      </td>     <td width="91" valign="top">       <p>DR2008002</p>      </td>     <td width="61" valign="top">       <p>Carrie</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/62</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; GE (reporter)</p>      </td>     <td width="91" valign="top">       <p>GE2008001</p>      </td>     <td width="61" valign="top">       <p>Allen</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 33-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/63</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; GE (reporter)</p>      </td>     <td width="91" valign="top">       <p>GE2008002</p>      </td>     <td width="61" valign="top">       <p>Corey</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/63</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Philips (reporter)</p>      </td>     <td width="91" valign="top">       <p>PH2008001</p>      </td>     <td width="61" valign="top">       <p>Adrian</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 34-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/64</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Philips (reporter)</p>      </td>     <td width="91" valign="top">       <p>PH2008002</p>      </td>     <td width="61" valign="top">       <p>Connie</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/64</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Spacelabs </p>      </td>     <td width="91" valign="top">       <p>SP2008001</p>      </td>     <td width="61" valign="top">       <p>Arthur</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 35-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/65</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Spacelabs </p>      </td>     <td width="91" valign="top">       <p>SP2008002</p>      </td>     <td width="61" valign="top">       <p>Clark</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/65</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Welch Allyn</p>      </td>     <td width="91" valign="top">       <p>WA2008001</p>      </td>     <td width="61" valign="top">       <p>Andrea</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 36-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/66</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Welch Allyn</p>      </td>     <td width="91" valign="top">       <p>WA2008002</p>      </td>     <td width="61" valign="top">       <p>Camille</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/66</p>      </td>     </tr> </table><H3>Evaluation</H3><p>Project manager or monitor will observe the displays provided by the DOR and partner DOC. The physiologic parameters and their measurement values, including the time of parameter measurement will be compared. The type of display/documentation by the DOC is not constrained, it need only be clinically useful.</p><p>Success: If the patient, the minimum number of parameters, measurements and time of measurement sent by the sending system matches those received by the receiving system before and after the interruption and restoration of communication that will indicate the step in the test has been successful. In particular, the systems must be able to attribute data to the correct patient during the entire test. If the sending system stores data that failed to reach the receiving system and sends it later, this should be called to the monitor&rsquo;s attention.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (94, 1, 0, '2009-11-24 10:53:16.273', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This test applies  to DOCs that are able to receive messages from more than one DOR. In this test,  multiple DORs send a series of messages for each patient to a DOC. <em>If desired, multiple DOCs can participate in  this test at the same time, if agreed to with a monitor.</em> </p> <p>This is a  scheduled test that follows one-to-one testing for the DORs and DOCs. It  requires coordination among the partnering systems. This test verifies the  ability to receive multiple messages from multiple sending systems containing  data for multiple physiological parameters, each system sending data for two or  more patients (if the systems support multiple patients). DORs must coordinate  their efforts and send a sufficient number of messages so that the DOC receives  at least two messages from each sending system in a time interval that includes  the other sending systems. This test applies to gateways that transmit multiple  messages for the same patient or patients AND to a gateway that transmits only  one set of parameters for one or more patients (e.g., vital signs monitor).</p> <p>NOTE:  DOFs will conduct similar tests within DEC_SPD_Many_to_One where the DOC subscribes to filtered  data. &nbsp;</p> <p>NOTE:  If the DOF is a standalone system, then the DOF must conduct also conduct the  DEC_Many_to_One_RF test. </p> <p>NOTE: Test names are the similar for DORs, DOFs  and DOCs. They play partner roles and DOCs are responsible for coordinating  with their DOR/DOF partners <em>during the  Connectathon </em>to assure that the required number of sending systems that are  needed are able to send the messages they will receive.</p> </p><H3>Description</H3><p>Conduct DEC_One_to_One_Communication  before proceeding.</p><p>Each DOR will send, and DOCs will receive physiologic parameters for two  patients from each DOR. If your system does not support multiple patients you  need to make this known to your test partners and the project manager.</p><p>DORs will send at least three messages for each of two patients with reasonable physiologic values for at least three supported  parameters. Parameters <strong>need not</strong> include relatively infrequently measured parameters (e.g., NIBP) <strong>unless</strong> the DOR only supports VSM data. If the DOR supports both validated and  unvalidated data, this test is performed with unvalidated data. </p><ol>         <li>Two  or more DORs coordinate to send messages such that at least three messages are  near-simultaneously sent from each DOR to the same DOC(s). Multiple DOCs may participate  in this test and each will receive the same messages and be evaluated  individually.</li>     <li>The  DORs agree on the interval between messages so that the DOC(s) are tested with  the DORs&rsquo; messages over the same time period.</li> </ol><p>PATIENT IDENTIFICATION:</p><p>For systems NOT using PAM or PDQ to obtain patient demographics, the patients for this test in January 2008 are given below. Additional patients can be created using the same pattern.</p><table border="1" cellspacing="0" cellpadding="0">     <tr>      <td width="133" valign="top"> <p>System</p> </td>     <td width="91" valign="top"> <p>MRN</p> </td>     <td width="67" valign="top"> <p>First Name</p> </td>     <td width="61" valign="top"> <p>Last Name</p> </td>     <td width="127" valign="top"> <p>Location</p> </td>     <td width="79" valign="top"> <p>Mother&rsquo;s Maiden Name</p> </td>     <td width="73" valign="top"> <p>DOB</p> </td>     </tr>     <tr>      <td width="133" valign="top"> <p>&nbsp; B Braun</p> </td>     <td width="91" valign="top"> <p>BB2008003</p> </td>     <td width="67" valign="top"> <p>Eddie</p> </td>     <td width="61" valign="top"> <p>Frank</p> </td>     <td width="127" valign="top"> <p>3 East ICU - 31-1</p> </td>     <td width="79" valign="top"> <p>Grant</p> </td>     <td width="73" valign="top"> <p>1/1/61</p> </td>     </tr>     <tr>      <td width="133" valign="top"> <p>&nbsp; B Braun</p> </td>     <td width="91" valign="top"> <p>BB2008004</p> </td>     <td width="67" valign="top"> <p>George</p> </td>     <td width="61" valign="top"> <p>Harris</p> </td>     <td width="127" valign="top"> <p>4 West ICU 31-1</p> </td>     <td width="79" valign="top"> <p>Ingram</p> </td>     <td width="73" valign="top"> <p>1/1/61</p> </td>     </tr>     <tr>      <td width="133" valign="top"> <p>&nbsp; Draeger (reporter)</p> </td>     <td width="91" valign="top"> <p>DR2008003</p> </td>     <td width="67" valign="top"> <p>Edie</p> </td>     <td width="61" valign="top"> <p>Frank</p> </td>     <td width="127" valign="top"> <p>3 East ICU &ndash; 32-1</p> </td>     <td width="79" valign="top"> <p>Grant</p> </td>     <td width="73" valign="top"> <p>1/1/62</p> </td>     </tr>     <tr>      <td width="133" valign="top"> <p>&nbsp; Draeger (reporter)</p> </td>     <td width="91" valign="top"> <p>DR2008004</p> </td>     <td width="67" valign="top"> <p>Glenda</p> </td>     <td width="61" valign="top"> <p>Harris</p> </td>     <td width="127" valign="top"> <p>4 West ICU 32-1</p> </td>     <td width="79" valign="top"> <p>Ingram</p> </td>     <td width="73" valign="top"> <p>1/1/62</p> </td>     </tr>     <tr>      <td width="133" valign="top"> <p>&nbsp; GE (reporter)</p> </td>     <td width="91" valign="top"> <p>GE2008003</p> </td>     <td width="67" valign="top"> <p>Ernie</p> </td>     <td width="61" valign="top"> <p>Frank</p> </td>     <td width="127" valign="top"> <p>3 East ICU &ndash; 33-1</p> </td>     <td width="79" valign="top"> <p>Grant</p> </td>     <td width="73" valign="top"> <p>1/1/63</p> </td>     </tr>     <tr>      <td width="133" valign="top"> <p>&nbsp; GE (reporter)</p> </td>     <td width="91" valign="top"> <p>GE2008004</p> </td>     <td width="67" valign="top"> <p>Glen</p> </td>     <td width="61" valign="top"> <p>Harris</p> </td>     <td width="127" valign="top"> <p>4 West ICU 33-1</p> </td>     <td width="79" valign="top"> <p>Ingram</p> </td>     <td width="73" valign="top"> <p>1/1/63</p> </td>     </tr>     <tr>      <td width="133" valign="top"> <p>&nbsp; Philips (reporter)</p> </td>     <td width="91" valign="top"> <p>PH2008002</p> </td>     <td width="67" valign="top"> <p>Ethel</p> </td>     <td width="61" valign="top"> <p>Frank</p> </td>     <td width="127" valign="top"> <p>3 East ICU &ndash; 34-1</p> </td>     <td width="79" valign="top"> <p>Grant</p> </td>     <td width="73" valign="top"> <p>1/1/64</p> </td>     </tr>     <tr>      <td width="133" valign="top"> <p>&nbsp; Philips (reporter)</p> </td>     <td width="91" valign="top"> <p>PH2008004</p> </td>     <td width="67" valign="top"> <p>Gert</p> </td>     <td width="61" valign="top"> <p>Harris</p> </td>     <td width="127" valign="top"> <p>4 West ICU 34-1</p> </td>     <td width="79" valign="top"> <p>Ingram</p> </td>     <td width="73" valign="top"> <p>1/1/64</p> </td>     </tr>     <tr>      <td width="133" valign="top"> <p>&nbsp; Spacelabs </p> </td>     <td width="91" valign="top"> <p>SP2008003</p> </td>     <td width="67" valign="top"> <p>Edward</p> </td>     <td width="61" valign="top"> <p>Frank</p> </td>     <td width="127" valign="top"> <p>3 East ICU &ndash; 35-1</p> </td>     <td width="79" valign="top"> <p>Grant</p> </td>     <td width="73" valign="top"> <p>1/1/65</p> </td>     </tr>     <tr>      <td width="133" valign="top"> <p>&nbsp; Spacelabs </p> </td>     <td width="91" valign="top"> <p>SP2008004</p> </td>     <td width="67" valign="top"> <p>Gary</p> </td>     <td width="61" valign="top"> <p>Harris</p> </td>     <td width="127" valign="top"> <p>4 West ICU 35-1</p> </td>     <td width="79" valign="top"> <p>Ingram</p> </td>     <td width="73" valign="top"> <p>1/1/65</p> </td>     </tr>     <tr>      <td width="133" valign="top"> <p>&nbsp; Welch Allyn</p> </td>     <td width="91" valign="top"> <p>WA2008002</p> </td>     <td width="67" valign="top"> <p>E.</p> </td>     <td width="61" valign="top"> <p>Frank</p> </td>     <td width="127" valign="top"> <p>3 East ICU &ndash; 36-1</p> </td>     <td width="79" valign="top"> <p>Grant</p> </td>     <td width="73" valign="top"> <p>1/1/66</p> </td>     </tr>     <tr>      <td width="133" valign="top"> <p>&nbsp; Welch Allyn</p> </td>     <td width="91" valign="top"> <p>WA2008004</p> </td>     <td width="67" valign="top"> <p>E.</p> </td>     <td width="61" valign="top"> <p>Harris</p> </td>     <td width="127" valign="top"> <p>4 West ICU 36-1</p> </td>     <td width="79" valign="top"> <p>Ingram</p> </td>     <td width="73" valign="top"> <p>1/1/66</p> </td>     </tr> </table><p>RELATED TEST:</p><p>If supported, the DORs may conduct this test with any number of DOFs and DOCs at the same time.</p><H3>Evaluation</H3><p>Project manager or monitor will observe the displays provided by the sending systems and partner receiver. The physiologic parameters and their measurement values, including the time the message is sent by the DOR and time of receipt by the DOC will be compared. The type of display/documentation by the DOC is not constrained, it need only be clinically useful.</p><p>Success: If the patients, the minimum number and values of the parameters, and the time of measurement sent by the DORs matches those received by the DOC that will indicate the test has been successful. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (95, 1, 0, '2009-11-24 10:53:16.276', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This test applies  to DOFs that are able to receive messages from more than one DOR. The DOFs in  this test are standalone DOFs and <em>not</em> part of a single DOR and DOF system. DOFs that are integrated with DORs should  not perform this test. In this test, multiple DORs send a series of messages  for each patient to one or more DOFs. <em>If  desired, multiple DOCs can participate in this test at the same time, if agreed  to with a monitor.</em> </p> <p>This is a scheduled  test that follows one-to-one testing for the systems under test. It requires  coordination among the partnering systems. This test verifies the ability to  receive multiple messages from multiple sending systems containing data for  multiple physiological parameters, each system sending data for two or more  patients (if the systems support multiple patients). DORs must coordinate their  efforts and send a sufficient number of messages so that the DOF receives at  least two messages from each sending system in a time interval that includes  the other sending systems. This test applies to systems that transmit multiple  messages for the same patient or patients AND to systems that transmits only  one set of parameters for one or more patients (e.g., vital signs monitor).</p> <p>NOTE:  DOFs will conduct similar tests within DEC_SPD_Many_to_One where the DOC subscribes to filtered  data.&nbsp; </p> <p>NOTE:  If the DOF is a standalone system, then the DOF must conduct also conduct this  DEC_Many_to_One_RF test. </p> <p>NOTE: Test names are the similar for DORs, DOFs  and DOCs. They play partner roles and DOCs are responsible for coordinating  with their DOR/DOF partners <em>during the  Connectathon </em>to assure that the required number of sending systems that are  needed are able to send the messages they will receive.</p> </p><H3>Description</H3><p>Conduct DEC_One_to_One_Communication  before proceeding.</p><p>Each DOR will send, and DOFs will receive physiologic parameters for two  patients from each DOR. If your system does not support multiple patients you  need to make this known to your test partners and the project manager.</p><p>DORs will send at least three messages for each of two patients with reasonable physiologic values for at least three supported  parameters. Parameters <strong>need not</strong> include relatively infrequently measured parameters (e.g., NIBP) <strong>unless</strong> the DOR only supports VSM data. If the DOR supports both validated and  unvalidated data, this test is performed with unvalidated data. </p><ol>         <li>Two  or more DORs coordinate to send messages such that at least three messages are  near-simultaneously sent from each DOR to the same DOF. Multiple DOFs may  participate in this test and each will receive the same messages and be  evaluated individually.</li>     <li>The  DORs agree on the interval between messages so that the DOF(s) are tested with  the DORs&rsquo; messages over the same time period.</li> </ol><p>PATIENT IDENTIFICATION:</p><p>For systems NOT using PAM or PDQ to obtain patient demographics, the patients for this test in    January 2008 are given below. Additional patients can be created using the same pattern.</p><table border="1" cellspacing="0" cellpadding="0">     <tr>      <td width="133" valign="top">       <p>System</p>      </td>     <td width="91" valign="top">       <p>MRN</p>      </td>     <td width="67" valign="top">       <p>First Name</p>      </td>     <td width="61" valign="top">       <p>Last Name</p>      </td>     <td width="127" valign="top">       <p>Location</p>      </td>     <td width="79" valign="top">       <p>Mother&rsquo;s Maiden Name</p>      </td>     <td width="73" valign="top">       <p>DOB</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; B Braun</p>      </td>     <td width="91" valign="top">       <p>BB2008003</p>      </td>     <td width="67" valign="top">       <p>Eddie</p>      </td>     <td width="61" valign="top">       <p>Frank</p>      </td>     <td width="127" valign="top">       <p>3 East ICU - 31-1</p>      </td>     <td width="79" valign="top">       <p>Grant</p>      </td>     <td width="73" valign="top">       <p>1/1/61</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; B Braun</p>      </td>     <td width="91" valign="top">       <p>BB2008004</p>      </td>     <td width="67" valign="top">       <p>George</p>      </td>     <td width="61" valign="top">       <p>Harris</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 31-1</p>      </td>     <td width="79" valign="top">       <p>Ingram</p>      </td>     <td width="73" valign="top">       <p>1/1/61</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Draeger (reporter)</p>      </td>     <td width="91" valign="top">       <p>DR2008003</p>      </td>     <td width="67" valign="top">       <p>Edie</p>      </td>     <td width="61" valign="top">       <p>Frank</p>      </td>     <td width="127" valign="top">       <p>3 East ICU &ndash; 32-1</p>      </td>     <td width="79" valign="top">       <p>Grant</p>      </td>     <td width="73" valign="top">       <p>1/1/62</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Draeger (reporter)</p>      </td>     <td width="91" valign="top">       <p>DR2008004</p>      </td>     <td width="67" valign="top">       <p>Glenda</p>      </td>     <td width="61" valign="top">       <p>Harris</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Ingram</p>      </td>     <td width="73" valign="top">       <p>1/1/62</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; GE (reporter)</p>      </td>     <td width="91" valign="top">       <p>GE2008003</p>      </td>     <td width="67" valign="top">       <p>Ernie</p>      </td>     <td width="61" valign="top">       <p>Frank</p>      </td>     <td width="127" valign="top">       <p>3 East ICU &ndash; 33-1</p>      </td>     <td width="79" valign="top">       <p>Grant</p>      </td>     <td width="73" valign="top">       <p>1/1/63</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; GE (reporter)</p>      </td>     <td width="91" valign="top">       <p>GE2008004</p>      </td>     <td width="67" valign="top">       <p>Glen</p>      </td>     <td width="61" valign="top">       <p>Harris</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 33-1</p>      </td>     <td width="79" valign="top">       <p>Ingram</p>      </td>     <td width="73" valign="top">       <p>1/1/63</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Philips (reporter)</p>      </td>     <td width="91" valign="top">       <p>PH2008002</p>      </td>     <td width="67" valign="top">       <p>Ethel</p>      </td>     <td width="61" valign="top">       <p>Frank</p>      </td>     <td width="127" valign="top">       <p>3 East ICU &ndash; 34-1</p>      </td>     <td width="79" valign="top">       <p>Grant</p>      </td>     <td width="73" valign="top">       <p>1/1/64</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Philips (reporter)</p>      </td>     <td width="91" valign="top">       <p>PH2008004</p>      </td>     <td width="67" valign="top">       <p>Gert</p>      </td>     <td width="61" valign="top">       <p>Harris</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 34-1</p>      </td>     <td width="79" valign="top">       <p>Ingram</p>      </td>     <td width="73" valign="top">       <p>1/1/64</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Spacelabs </p>      </td>     <td width="91" valign="top">       <p>SP2008003</p>      </td>     <td width="67" valign="top">       <p>Edward</p>      </td>     <td width="61" valign="top">       <p>Frank</p>      </td>     <td width="127" valign="top">       <p>3 East ICU &ndash; 35-1</p>      </td>     <td width="79" valign="top">       <p>Grant</p>      </td>     <td width="73" valign="top">       <p>1/1/65</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Spacelabs </p>      </td>     <td width="91" valign="top">       <p>SP2008004</p>      </td>     <td width="67" valign="top">       <p>Gary</p>      </td>     <td width="61" valign="top">       <p>Harris</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 35-1</p>      </td>     <td width="79" valign="top">       <p>Ingram</p>      </td>     <td width="73" valign="top">       <p>1/1/65</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Welch Allyn</p>      </td>     <td width="91" valign="top">       <p>WA2008002</p>      </td>     <td width="67" valign="top">       <p>E.</p>      </td>     <td width="61" valign="top">       <p>Frank</p>      </td>     <td width="127" valign="top">       <p>3 East ICU &ndash; 36-1</p>      </td>     <td width="79" valign="top">       <p>Grant</p>      </td>     <td width="73" valign="top">       <p>1/1/66</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Welch Allyn</p>      </td>     <td width="91" valign="top">       <p>WA2008004</p>      </td>     <td width="67" valign="top">       <p>E.</p>      </td>     <td width="61" valign="top">       <p>Harris</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 36-1</p>      </td>     <td width="79" valign="top">       <p>Ingram</p>      </td>     <td width="73" valign="top">       <p>1/1/66</p>      </td>     </tr> </table><p>RELATED TEST:</p><p>If supported, the DORs may conduct this test with any number of DOFs and DOCs at the same time.</p><H3>Evaluation</H3><p>Project manager or monitor will observe the displays provided by the sending systems and partner receiver. The physiologic parameters and their measurement values, including the time the message is sent by the DOR and time of receipt by the DOC will be compared. The type of display/documentation by the DOF is not constrained, and it need NOT be clinically useful.</p><p>Success: If the patients, the minimum number and values of the parameters, and the time of measurement sent by the DORs matches those received by the DOF that will indicate the test has been successful. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (96, 1, 0, '2009-11-24 10:53:16.278', 'epoiseau', '<h3>Special Instructions</h3> <p>Logistics for the test will be handled by special arrangement of the Project Manager.</p>  <p>DEC_Multiple_DOR is defined in the context of DOR/DOC combinations where the DORs are capable of supporting any device that transmits a sequence of messages for one or more subjects. If your DOR does not transmit a sequence of messages over an extended period of time, do not perform this test.</p>  <p>Since coordination will be difficult, the DORs should be prepared to send a lengthy series of values. In the above table it is suggested that DORs send data for multiple patients, but this is optional.  </p>  <h3>Description</h3> <p>DORs will send messages with reasonable physiologic values for supported parameters as described in the previous section where the DOR sends data for Multiple Simultaneous Patients if the DOR is capable of sending data for more than one patient. If the DOR is not capable of sending data for multiple patients it will send data for a single patient.</p>  <p>Two or more DORs coordinate transmissions to a single DOC. Each DOC is responsible for testing against two or more DORs with multiple transmissions over an interval long enough to assure coordination among the multiple DORs and the DOC. At least two transmissions will be sent from the DOR with the lowest message frequency. DORs should send messages from multiple patients if multiple patients are supported. Optional: If coordination permits, multiple DOCs may participate simultaneously.</p>  <p>A DOC need only participate in one test, with two or more DORs. DORs may be required to participate multiple times along with other DORs in order to fulfill the requirements, or may not be needed if all DOCs have completed the test before the DOR is ready.</p>  <h3>Evaluation</h3> <p>Project manager or monitor will observe the displays provided by the DORs and partner DOC. The physiologic parameters and their measurement values, including the time of parameter measurement will be compared. The type of display/documentation by the DOC is not constrained, it need only be clinically useful.</p>  <p>If the minimum number of parameters, measurements and time of measurement sent by the DOR matches those received by the DOC that will indicate the test has been successful. Note that the data must match the patient.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (97, 1, 0, '2009-11-24 10:53:16.281', 'epoiseau', '<H3>Special Instructions</H3>  <p>This test involves multiple DORs, DOFs an DOCs. DORs and DOFs send to multiple DOCs, and DOCs receive from multiple DORs and DOFs. The SPD option is not evaluated in this test; DOCs implementing SPD with one or more DOFs will query for any convenient patients and parameters meeting the requirements described here. </p>  <p>This test applies to </p> <ul> <li>DORs, DOFs and DOCs</li>  <li>     DORs with DOFs in the same system, should test both the DOR function and the DOF; in this test the DOC uses the query function to filter data in a convenient manner</li> <li>     Standalone DOFs, test the input side as if it were a DOC without an SPD query and the output side as the filter. The test may require a DOR to assist as a partner to supply the patient''s data to the DOF.  </li> </ul>   <p>Systems are responsible for coordinating with their partners in advance of the Connectathon to assure that they will have the required number of systems needed for testing. It is necessary to determine that the partnering systems support the same physiologic or other parameters, with consistent coding. For this reason, PCD recommends (and will shortly require) that parameters be coded as defined by the Rosetta Terminology Mapping project. Consult the project manager to determine if this requirement applies. </p>  <p>DORs and DOFs will send data for two patients to multiple DOCs, and DOCs will receive physiologic and/or other parameters for two or more patients from two or more DORs and/or DOFs. If your system does not support multiple patients or multiple DORs, DOFs, DOCs, with available parameters, you need to make this known to your test partners and the project manager. </p>  <H3>Description</H3> <p>A monitor will assist the participating systems organize this test. Participants and the monitor will consider how best to make this test available for all systems while minimizing the number of times a system must participate. A system will need to test only once, but may be asked to test multiple times to assist other systems. </p>  <p>The DORs send a series of messages (as described in the test steps provided below) to the DOFs and DOCs and DOFs will send messages to the DOCs. Messages include multiple physiologic and/or operational parameters. </p>  <p>DORs and DOFs send a sufficient number of messages for each of the two patients they select, and receiving DOFs and DOCs will document successful receipt of the data. Systems test parameters that partners can support. Each message will contain reasonable values for at least two parameters. If the DOR supports both validated and unvalidated data, this test is performed with unvalidated data. Each message may include any number of additional parameters. </p>  <p>Parameter values should be realistic for a patient in a cardiac ICU bed or on an OR table. </p>  <p>Messages the systems send for the two patients are interleaved in some manner. </p>  <p>Parameters should be sent from actual devices (preferred), simulators or, if necessary from parameter tables provided by the Project Manager (least desirable). </p>  <u>Patient Identification</u> <p>The AR''s patient list is developed using the rules in Kudu for test PCD_Patient_Demographics found at http://ihe-kudu.wustl.edu/na2009/connectathon_test.php.  For this test, the AR system will use any two patients from the list developed with this process. </p>  <H3>Evaluation</H3> <p>Project manager or monitor will observe the displays and/or logs provided by the sending system(s) and partner(s). The patients'' names and/or medical record numbers (MRNs), physiologic and other parameters, their measurement values, and the time of parameter transmission / acquisition will be compared. The type of display/documentation by the receiving system is not constrained, it need only be clinically useful. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (98, 1, 0, '2009-11-24 10:53:16.283', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This tests a DOF  that is part of a DOR/DOF system that has the ability to send messages to  multiple DOCs. It is a redundant test of the ability of the DOC to receive  messages containing data for one or more patients. The test verifies the  ability for the DOF to send multiple messages (or a DOF supporting only VSMs to  send messages) to multiple DOCs. &nbsp;The  test verifies the ability to send, and for a DOC to receive and verify the DOF&rsquo;s  ability to send multiple messages containing data with multiple physiological  parameters for two patients (or only a single patient if multiple patients are  not supported). If your system does not support multiple patients, you need to  make this known to your test partners and the project manager.</p> <p> The DOF must  coordinate this test with multiple DOCs. The sending system is responsible for  making sure each of the receiving systems can receive and display at least a  minimum set of four parameters <em>in advance  of the Connectathon.</em> </p> <p> There are three  variations of this test; be sure you select the right one(s):</p> <ul>     <li>DEC_One_to_Many_Communication_RC </li>     <ul>      <li>DOR  and two or more DOCs </li>      <li>DOR  with DOF in the same system, testing the DOR function and not the DOF; the DOC  does not use the query function to request filtered data </li>     </ul>     <li>DEC_One_to_Many_Communication_FC</li>     <ul>      <li>DOR  with DOF in the same system, testing the DOF function and not the DOR; the DOC provides  the query function to request filtered data </li>     </ul>     <li>DEC_One_to_Many_Communication_RFC </li>     <ul>      <li>Standalone  DOF tests the output side to verify the ability to respond to two or more DOCs </li>     </ul> </ul> <p>NOTE:<strong> </strong>If  the system is a DOF in the same system as a DOR, then the DOF must test with multiple  DOCs. </p> <p>  NOTE: A test with one or multiple standalone DOFs (and  possibly DOCs) receiving messages from a single DOR is considered redundant  because the standalone DOF in that case looks like a DOC to the DOR.</p> <p>NOTE:  The DEC_One_to_Many_Communication_RFC test is appropriate for a standalone DOF  that relies upon a DOR for data. </p> <p>NOTE: Test names are the same for DORs, DOFs and  DOCs. They play partner roles and DORs are responsible for coordinating with  their partners <em>in advance of the  Connectathon</em> to assure that the required number of DOCs needed are able to  receive the messages they will send.</p> <p>RELATED TESTS:</p> <p>This test may be combined with the DEC_SPD_By_Location test.</p> </p><H3>Description</H3><p>Conduct  DEC_One_to_One_Communication testing before proceeding.</p><p>This test applies  to systems that transmit multiple messages for the same patient or patients AND  to a gateway that transmits only one set of parameters for one or more patients  (e.g., vital signs monitor). This test applies only to DOFs that send messages  to multiple DOCs.</p><ol>     <li>Each  DOC terminates any existing subscription.</li>     <li>Each  DOC subscribes to the DOF for any supported filter type that both systems  support. The two (or more) DOCs need not send the same query but <strong>must</strong> request the same patients. A  minimum of two messages consistent with the subscription request are received.</li>     <li>A  DOF sends a series of messages to two or more DOCs. Messages include at two  patients (if multiple patients are supported) and multiple physiological  parameters. Parameters include sampled continuous parameters (e.g., heart rate  and blood pressure) if supported, or VSM data if that is the only data type  supported. Messages <strong>need not include</strong> relatively infrequently measured parameters (e.g., NIBP). For DOFs that are  part of a DOR/DOF system, the DOR portion must also test using DEC_ One_to_Many_Communication _RC. </li>     <li>Messages  will alternate between the two patients. I.e., a message for patient #1 is  followed by a message for patient #2 before another message is sent for patient  #1. Messages should not be closer in time than 30 seconds apart.</li> </ol><p>Sending systems  send the same messages to two or more DOCs.</p><p>PATIENT IDENTIFICATION:</p><p>For systems NOT using PAM or PDQ to obtain patient demographics, the patients for this test in    January 2008 are given below. Additional patients can be created using the same pattern.</p><table border="1" cellspacing="0" cellpadding="0">     <tr>      <td width="133" valign="top">       <p align="center">        <strong>System</strong>       </p>      </td>     <td width="91" valign="top">       <p align="center">        <strong>MRD</strong>       </p>      </td>     <td width="61" valign="top">       <p align="center">        <strong>First Name</strong>       </p>      </td>     <td width="67" valign="top">       <p align="center">        <strong>Last Name</strong>       </p>      </td>     <td width="127" valign="top">       <p align="center">        <strong>Location</strong>       </p>      </td>     <td width="79" valign="top">       <p align="center">        <strong>Mother&rsquo;s Maiden Name</strong>       </p>      </td>     <td width="73" valign="top">       <p align="center">        <strong>DOB</strong>       </p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; B Braun</p>      </td>     <td width="91" valign="top">       <p>BB2008001</p>      </td>     <td width="61" valign="top">       <p>Albert</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU - 31-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/61</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; B Braun</p>      </td>     <td width="91" valign="top">       <p>BB2008002</p>      </td>     <td width="61" valign="top">       <p>Charles</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/61</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Draeger (reporter)</p>      </td>     <td width="91" valign="top">       <p>DR2008001</p>      </td>     <td width="61" valign="top">       <p>Amy</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 32-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/62</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Draeger (reporter)</p>      </td>     <td width="91" valign="top">       <p>DR2008002</p>      </td>     <td width="61" valign="top">       <p>Carrie</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/62</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; GE (reporter)</p>      </td>     <td width="91" valign="top">       <p>GE2008001</p>      </td>     <td width="61" valign="top">       <p>Allen</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 33-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/63</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; GE (reporter)</p>      </td>     <td width="91" valign="top">       <p>GE2008002</p>      </td>     <td width="61" valign="top">       <p>Corey</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/63</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Philips (reporter)</p>      </td>     <td width="91" valign="top">       <p>PH2008001</p>      </td>     <td width="61" valign="top">       <p>Adrian</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 34-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/64</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Philips (reporter)</p>      </td>     <td width="91" valign="top">       <p>PH2008002</p>      </td>     <td width="61" valign="top">       <p>Connie</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/64</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Spacelabs </p>      </td>     <td width="91" valign="top">       <p>SP2008001</p>      </td>     <td width="61" valign="top">       <p>Arthur</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 35-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/65</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Spacelabs </p>      </td>     <td width="91" valign="top">       <p>SP2008002</p>      </td>     <td width="61" valign="top">       <p>Clark</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/65</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Welch Allyn</p>      </td>     <td width="91" valign="top">       <p>WA2008001</p>      </td>     <td width="61" valign="top">       <p>Andrea</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 36-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/66</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Welch Allyn</p>      </td>     <td width="91" valign="top">       <p>WA2008002</p>      </td>     <td width="61" valign="top">       <p>Camille</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/66</p>      </td>     </tr> </table><H3>Evaluation</H3><p>Project manager or monitor will observe the displays  provided by the sending system and receiving partners. The physiologic  parameters and their measurement values, including the time of parameter  measurement will be compared. The type of display/documentation by the  receiving system is not constrained, it need only be clinically useful.</p><p>Both DOCs should display the same patient  demographic and physiologic data for the two patients as the DOF was capable of  sending unfiltered (see the DOR test for the combined DOR/DOF system), with the  understanding that the two may not support all of the parameters transmitted.</p><p>Success: If the patients, the minimum number of  parameters, the measurements and the time of measurement sent by the DOR  matches those received by the DOC that will indicate the test has been  successful. </p><p>If the DEC_SPD_By_Location test is conducted at this time, it will be  evaluated separately, as described in that test.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (99, 1, 0, '2009-11-24 10:53:16.287', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This tests a DOR  that has the ability to send messages to multiple DOCs. It is a redundant test  of the ability of the DOC to receive messages containing data for one or more  patients. The test verifies the ability for a DOR to send multiple messages (or  a DOR supporting only VSMs to send messages) to multiple DOCs. Messages contain  data with multiple physiological parameters for two patients (or only a single  patient if multiple patients are not supported). If your system does not  support multiple patients, you need to make this known to your test partners  and the project manager.</p> <p>  The DOR must  coordinate this test with multiple DOCs. The sending system is responsible for  making sure each of the receiving systems can receive and display at least a  minimum set of four parameters <em>in advance  of the Connectathon.</em> </p> <p>  There are three  variations of this test; be sure you select the right one(s):</p> <ul>     <li>DEC_One_to_Many_Communication_RC</li>     <ul>      <li>DOR  and two or more DOCs </li>      <li>DOR  with DOF in the same system, testing the DOR function and not the DOF; the DOC  does not use the query function to request filtered data </li>     </ul>     <li>DEC_One_to_Many_Communication_FC </li>     <ul>      <li>DOR  with DOF in the same system, testing the DOF function and not the DOR; the DOC provides  the query function to request filtered data </li>     </ul>     <li>DEC_One_to_Many_Communication_RFC&nbsp;&nbsp; </li>     <ul>      <li>Standalone DOF tests the output side to  verify the ability to respond to two or more DOCs </li>     </ul> </ul> <p>NOTE: If  the system is a DOF in the same system as a DOR, then the DOF must test with multiple  DOCs. </p> <p>  NOTE: A test with one or multiple standalone DOFs (and  possibly DOCs) receiving messages from a single DOR is considered redundant because  the standalone DOF in that case looks like a DOC to the DOR.</p> <p>NOTE:  The DEC_One_to_Many_Communication _RFC test is appropriate for a standalone  DOF that relies upon a DOR for data and sends messages to multiple DOCS. </p> <p>NOTE: Test names are the same for DORs, DOFs and  DOCs. They play partner roles and DORs are responsible for coordinating with  their partners <em>in advance of the  Connectathon</em> to assure that the required number of DOCs needed are able to  receive the messages they will send.</p> <p>RELATED TESTS:</p> <p>If two or more DORs are available at the time of the test, they may coordinate their effort and conduct the DEC_Many_To_One test simultaneously.</p> </p><H3>Description</H3><p> <p>Conduct  DEC_One_to_One_Communication testing before proceeding.</p>     <p>  This test applies  to systems that transmit multiple messages for the same patient or patients AND  to a gateway that transmits only one set of parameters for one or more patients  (e.g., vital signs monitor). This test applies only to DORs that send messages to  multiple DOFs or DOCs; in this case we test with DOCs.</p>     <ol>      <li>A  DOR sends a series of messages to two or more DOCs. Messages include at least two  patients (if multiple patients are supported) and multiple physiological  parameters. Parameters include sampled continuous parameters (e.g., heart rate  and blood pressure) if supported, or VSM data if that is the only data type  supported. Messages <strong>need not include</strong> relatively infrequently measured parameters (e.g., NIBP). For DOFs that are  part of a DOR/DOF system also must test the DOF option in DEC_One_to_Many_Communication_FC. </li>      <li>Messages  will alternate between the two patients. I.e., a message for patient #1 is  followed by a message for patient #2 before another message is sent for patient  #1. Messages should not be closer in time than 30 seconds apart. A minimum of  two messages consistent with the subscription request are received.</li>     </ol>     <p>Sending systems send  the same messages to two or more DOCs.</p> </p><p>PATIENT IDENTIFICATION:</p><p>For systems NOT using PAM or PDQ to obtain patient demographics, the patients for this test in    January 2008 are given below. Additional patients can be created using the same pattern.</p><table border="1" cellspacing="0" cellpadding="0">     <tr>      <td width="133" valign="top">       <p align="center">        <strong>System</strong>       </p>      </td>     <td width="91" valign="top">       <p align="center">        <strong>MRD</strong>       </p>      </td>     <td width="61" valign="top">       <p align="center">        <strong>First Name</strong>       </p>      </td>     <td width="67" valign="top">       <p align="center">        <strong>Last Name</strong>       </p>      </td>     <td width="127" valign="top">       <p align="center">        <strong>Location</strong>       </p>      </td>     <td width="79" valign="top">       <p align="center">        <strong>Mother&rsquo;s Maiden Name</strong>       </p>      </td>     <td width="73" valign="top">       <p align="center">        <strong>DOB</strong>       </p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; B Braun</p>      </td>     <td width="91" valign="top">       <p>BB2008001</p>      </td>     <td width="61" valign="top">       <p>Albert</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU - 31-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/61</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; B Braun</p>      </td>     <td width="91" valign="top">       <p>BB2008002</p>      </td>     <td width="61" valign="top">       <p>Charles</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/61</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Draeger (reporter)</p>      </td>     <td width="91" valign="top">       <p>DR2008001</p>      </td>     <td width="61" valign="top">       <p>Amy</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 32-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/62</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Draeger (reporter)</p>      </td>     <td width="91" valign="top">       <p>DR2008002</p>      </td>     <td width="61" valign="top">       <p>Carrie</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/62</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; GE (reporter)</p>      </td>     <td width="91" valign="top">       <p>GE2008001</p>      </td>     <td width="61" valign="top">       <p>Allen</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 33-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/63</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; GE (reporter)</p>      </td>     <td width="91" valign="top">       <p>GE2008002</p>      </td>     <td width="61" valign="top">       <p>Corey</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/63</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Philips (reporter)</p>      </td>     <td width="91" valign="top">       <p>PH2008001</p>      </td>     <td width="61" valign="top">       <p>Adrian</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 34-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/64</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Philips (reporter)</p>      </td>     <td width="91" valign="top">       <p>PH2008002</p>      </td>     <td width="61" valign="top">       <p>Connie</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/64</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Spacelabs </p>      </td>     <td width="91" valign="top">       <p>SP2008001</p>      </td>     <td width="61" valign="top">       <p>Arthur</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 35-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/65</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Spacelabs </p>      </td>     <td width="91" valign="top">       <p>SP2008002</p>      </td>     <td width="61" valign="top">       <p>Clark</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/65</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Welch Allyn</p>      </td>     <td width="91" valign="top">       <p>WA2008001</p>      </td>     <td width="61" valign="top">       <p>Andrea</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 36-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/66</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Welch Allyn</p>      </td>     <td width="91" valign="top">       <p>WA2008002</p>      </td>     <td width="61" valign="top">       <p>Camille</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/66</p>      </td>     </tr> </table><H3>Evaluation</H3><p>Project manager or monitor will observe the displays  provided by the sending system and receiving partners. The physiologic  parameters and their measurement values, including the time of parameter  measurement will be compared. The type of display/documentation by the  receiving system is not constrained, it need only be clinically useful.</p><p>Both DOCs should display the same information for  the two patients, with the understanding that the two may not support all of  the parameters transmitted.</p><p>Success: If the patients, the minimum number of  parameters, the measurements and the time of measurement sent by the DOR  matches those received by the DOC that will indicate the test has been  successful. </p><p>If other tests (e.g., a PIB or the  DEC_Many_To_One_RC) test is conducted at this time, it will be evaluated separately,  as described in the individual tests listed above. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (100, 1, 0, '2009-11-24 10:53:16.291', 'epoiseau', '<H3>Special Instructions</H3> <H3>TEMPORARY Instruction - ignore reference to DOFs, and if you are a DOF see Manny</H3>   <p>This test applies to sending and receiving systems that transmit and receive multiple messages for the same patient or patients periodically, or nearly periodically. This is the fundamental test for many DEC systems, verifying the ability to send or receive multiple messages containing data for multiple physiological parameters for two or more patients. This test will apply with suitable assumptions if the system supports only a single patient. </p>  <p>If the system supports ONLY infrequent or aperiodic data, DO NOT utilize this test. Instead, use DEC_DOC_One_to_One_Communication_Infrequent_Data. Examples of those systems include infusion pumps which send information when an event occurs, a vital signs monitor that sends aggregated data on command, and NIBP devices or NIBP channels in a monitor. While an NIBP monitor may be scheduled to make measurements periodically, the intervals are too long for testing in a Connectathon. These systems conduct the test for infrequent data by triggering an event or taking a reading. </p>  <p>If the sending system sends both periodic and aperiodic / infrequent data, or the receiving system receives both, it is ONLY necessary to perform this test unless requested to assist another system with a test of infrequent data. </p>  <p>This test applies to these partner systems: </p> <ul> <li>DOR and DOC</li>  <li>DOF and DOC</li> <p>         - The DOC will query for all or a convenient group of available data</p> <li>DOR and a standalone DOF where the input of the DOF acts like a DOC</li>         <p>         - This should be combined into DOR, DOF and DOC testing</p> </ul>  <p>Developers are responsible for coordinating with their partners in advance of the Connectathon to assure that they will have the required number of partner systems that support the same physiologic or other parameters, with consistent coding. For this reason, PCD recommends (and will shortly require) that parameters be coded as defined by the Rosetta Terminology Mapping project. Consult the project manager to determine if this requirement applies. </p>  <p>Conduct this test for all system types that are supported, for example: </p> <ul> <li>Physiologic Monitor (bedside and/or perioperative monitors) </li> <p>         - Heart rate</p> <p>         - Blood pressure (invasive systolic, diastolic, mean) </p> <p>         - SpO2</p> <li>Anesthesia Ventilator </li> <p>         - Expiratory minute volume</p> <p>         - Percent oxygen</p> <p>         - Peak and mean pressure</p> </ul>  <p>If, for example, a system supports surgical physiologic monitors, messages will contain values for parameter types within the monitor (heart rate, invasive blood pressure, etc.) and for the anesthesia ventilator. </p>  <p>Systems will send and receive parameters for at least two patients. Patient demographics are defined consistent with instructions on the PCD_Patient_Demographics test page. If your system does not support multiple patients, you need to make this known to your test partners and the project manager. </p>  <u> Related Tests</u> <p>Developers may combine this test with: </p> <ul> <li>DEC_PIB_Option (PAM and/or PDQ in the Patient Identity Binding (PIB) option) </li> </ul>  <p>To obtain credit for these additional tests, include the data and steps consistent with that additional test. </p>  <p>Developers may wish to follow this test with: </p> <ul> <li>DEC_Multiple_DORs</li> </ul>  <H3>Description</H3> <p>Send a series of messages to the receiving system. Messages include multiple physiologic and/or operational parameters as appropriate for the devices, systems and parameters supported. </p>  <p>Send sufficient data for at least two patients to document successful transmission and receipt of the data. Within the group of partners, systems should test all system types they support (e.g., perioperative monitor and anesthesia ventilator monitor). Each message will contain reasonable values for at least four parameters for each system type, assuming that at least four parameters are supported (e.g., four or more for each patient and device type, such as heart rate; systolic, diastolic, mean invasive pressures). If the sending system supports both validated and unvalidated data, this test is performed with unvalidated data and then with a sample of validated data. Each message may include any number of additional parameters. </p>  <p>Parameter values should be realistic for a patient in an ICU, emergency room or step down unit. </p>  Parameter data obtained for each patient should be as close as in time to data for other patients as is convenient. </p>  <p>Parameters should be sent from actual devices (preferred), simulators or, if necessary from parameter tables provided by the Project Manager (least desirable). </p>  <u>Patient Identification</u> Refer to the PCD_Patient_Demographics table and select two appropriate patients. </p>  <H3>Evaluation</H3> <p>Project manager or monitor will observe the displays provided by the sending and receiving system(s). The patients'' names and/or medical record numbers (MRNs), physiologic and other parameters, their measurement values, and the time of parameter measurement/acquisition will be compared. The type of display/documentation by the receiving system is not constrained, it need only be clinically useful. </p>  <p>NOTE: If other tests are conducted with this test, they will evaluated as described for those tests and the evaluation will be recorded for those tests. </p>   ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (101, 1, 0, '2009-11-24 10:53:16.295', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This is the fundamental test for DEC systems, verifying the ability to send or receive multiple    messages containing data for multiple physiological parameters for two or more patients. This    test will apply with suitable assumptions if only a single patient is supported by a system. This    test applies to sending and receiving systems that transmit multiple messages for the same    patient or patients and may include messages for a vital signs monitor (VSM) or other device that    sends messages for patients aperiodically &ndash; but only if the system supports continuous    measurements as well. For a DOR system that transmits only one set of parameters for one or more    patients (e.g., vital signs monitor) use test DEC_Vital_Signs_Monitor_RC or    DEC_Vital_Signs_Monitor_RFC instead.</p> <p>There are two variations of this test; be sure you select the right one(s):</p> <ul>     <li>DEC_One_to_One_Communication_RC </li>     <ul>      <li>DOR and a DOC </li>      <li>DOR with DOF in the same system, testing the DOR function and not the DOF; the DOC does not      use the query function to filter data </li>     </ul>     <li>DEC_One_to_One_Communication_RF</li>     <ul>      <li>Standalone DOF, testing the input side as if it were a DOC, will need a DOR as partner</li>     </ul> </ul> <p>NOTE: If the system is a DOF independent of a DOR, then the DOF must test as if it were a DOC    with a DOR (using DEC_One_to_One_Communication_RF). I.e., the DOF must receive messages from a    DOR. Tests of its ability to respond to subscriptions from a DOC are provided elsewhere. </p> <p>NOTE: Test names for this test are the same for DORs and DOCs. They play partner roles and DORs    are responsible for coordinating with their partners <b>in advance of the Connectathon</b> to    assure that the required number of receiving systems needed are able to receive the messages they    will send.</p> <p>The DOR and DOC conduct the tests for all system types they support from this list: </p> <ul>     <li>Physiologic Monitor (bedside and/or perioperative monitors), </li>     <li>Vital Signs Monitor, </li>     <li>Infusion Pump, </li>     <li>Ventilator,</li>     <li>Other as developed with the Project Manager</li> </ul> <p>If, for example, a system supports bedside monitors and infusion pumps, messages will contain    parameters for parameter types within the bedside monitor (heart rate, blood pressure, etc.) and    for the pump.</p> <p>DORs will send, and DOCs will receive physiologic and/or pump parameters for two patients. If    your system does not support multiple patients you need to make this known to your test partners    and the project manager.</p> <p>RELATED TESTS:</p> <p>Developers may combine this test with:</p> <ul>     <li>DEC_Interrupted_Communication</li>     <li>PAM_ID_Mgmt</li>     <li>PDQ_Exact_Name and PDQ_Multiple_Query</li>     <li>DEC_Validated_Parameters (would follow this test)</li> </ul> <p> Please consult documentation for those tests, which are briefly summarized here:    DEC_Interrupted_Communication: Each system (except VSMs) must conduct one test of    DEC_Interrupted_Communication to show the ability to resume communications following an    interruption of the data link. Either or both systems may conduct that test after successful    communication of the minimum number of messages at this time, but they may not do so    simultaneously. </p> <p>PAM, PDQ: If the DOR supports either or both of the PAM and PDQ options in the Patient Identity    Binding (PIB) option, the DOR may elect to test either or both of these tests at this time by    using the PIB option to obtain the patient&rsquo;s demographics in conducting the    DEC_One_to_One_Communication. To obtain credit for either of both of these tests, conduct the    test consistent with that test.</p> <p>DEC_Validated_Parameters: If partners are available it may be an efficient use of time to    conduct this test after successfully conducting the DEC_One_to_One_Communication test. Refer to    that test for details. </p> </p><H3>Description</H3><p>A DOR sends a series of messages (as described in the tests listed below) to a DOC. Messages    include multiple physiological parameters. Parameters should include sampled continuous    parameters (e.g., heart rate) and relatively infrequently measured parameters (e.g., NIBP) if    both are supported.</p><ol>     <li>DORs send at least three messages for each of two patients. Within the group of partners,     systems should test all system types they support (i.e., bedside, perioperative, vital signs     monitors; infusion pumps; ventilators). Each message will contain reasonable physiologic values     for at least six parameters for each system type (e.g., six or more for each patient&rsquo;s monitor     and six or more for each patient&rsquo;s pumps if both system types are supported). If the DOR     supports both validated and unvalidated data, this test is performed with unvalidated data. Each     message may include any number of additional parameters. If a system supports infrequent data     (e.g., NIBP), at least one instance of this data shall be sent in addition to the data types     sent in the other messages. Parameter values should be realistic for a patient in a cardiac ICU     bed or on an OR table.</li>     <li>Messages will alternate between the two patients. I.e., a message for patient #1 is followed     by a message for patient #2 before another message is sent for patient #1. Messages should not     be closer in time than 30 seconds apart.</li> </ol><p>If the system supports VSMs and other device types, then include one message (or message    sequence) from the VSM with one set data for multiple patients in this test. </p><p>Messages will alternate between patients (i.e., parameters for patient #1 are followed by    parameters for patient #2 before the next set of parameters are sent for patient #1). </p><p>Parameters should be sent from actual devices (preferred), simulators or, if necessary from    parameter tables provided by the Project Manager (least desirable).</p><p>PATIENT IDENTIFICATION:</p><p>For systems NOT using PAM or PDQ to obtain patient demographics, the patients for this test in    January 2008 are given below. Additional patients can be created using the same pattern.</p><table border="1" cellspacing="0" cellpadding="0">     <tr>      <td width="133" valign="top">       <p align="center">        <strong>System</strong>       </p>      </td>     <td width="91" valign="top">       <p align="center">        <strong>MRD</strong>       </p>      </td>     <td width="61" valign="top">       <p align="center">        <strong>First Name</strong>       </p>      </td>     <td width="67" valign="top">       <p align="center">        <strong>Last Name</strong>       </p>      </td>     <td width="127" valign="top">       <p align="center">        <strong>Location</strong>       </p>      </td>     <td width="79" valign="top">       <p align="center">        <strong>Mother&rsquo;s Maiden Name</strong>       </p>      </td>     <td width="73" valign="top">       <p align="center">        <strong>DOB</strong>       </p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; B Braun</p>      </td>     <td width="91" valign="top">       <p>BB2008001</p>      </td>     <td width="61" valign="top">       <p>Albert</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU - 31-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/61</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; B Braun</p>      </td>     <td width="91" valign="top">       <p>BB2008002</p>      </td>     <td width="61" valign="top">       <p>Charles</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/61</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Draeger (reporter)</p>      </td>     <td width="91" valign="top">       <p>DR2008001</p>      </td>     <td width="61" valign="top">       <p>Amy</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 32-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/62</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Draeger (reporter)</p>      </td>     <td width="91" valign="top">       <p>DR2008002</p>      </td>     <td width="61" valign="top">       <p>Carrie</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/62</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; GE (reporter)</p>      </td>     <td width="91" valign="top">       <p>GE2008001</p>      </td>     <td width="61" valign="top">       <p>Allen</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 33-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/63</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; GE (reporter)</p>      </td>     <td width="91" valign="top">       <p>GE2008002</p>      </td>     <td width="61" valign="top">       <p>Corey</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/63</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Philips (reporter)</p>      </td>     <td width="91" valign="top">       <p>PH2008001</p>      </td>     <td width="61" valign="top">       <p>Adrian</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 34-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/64</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Philips (reporter)</p>      </td>     <td width="91" valign="top">       <p>PH2008002</p>      </td>     <td width="61" valign="top">       <p>Connie</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/64</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Spacelabs </p>      </td>     <td width="91" valign="top">       <p>SP2008001</p>      </td>     <td width="61" valign="top">       <p>Arthur</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 35-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/65</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Spacelabs </p>      </td>     <td width="91" valign="top">       <p>SP2008002</p>      </td>     <td width="61" valign="top">       <p>Clark</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/65</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Welch Allyn</p>      </td>     <td width="91" valign="top">       <p>WA2008001</p>      </td>     <td width="61" valign="top">       <p>Andrea</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 36-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/66</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Welch Allyn</p>      </td>     <td width="91" valign="top">       <p>WA2008002</p>      </td>     <td width="61" valign="top">       <p>Camille</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/66</p>      </td>     </tr> </table><H3>Evaluation</H3><p>Project manager or monitor will observe the displays provided by the sending system and    partner. The physiologic parameters and their measurement values, including the time of parameter    measurement will be compared. The type of display/documentation by the receiving system is not    constrained, it need only be clinically useful.</p><p>Success: If the patients, the minimum number of parameters, the measurements and the time of    measurement sent by the DOR matches those received by the DOC that will indicate the step in the    test has been successful. </p><p>NOTE: If DEC_Interrupted_Communication, DEC_PIB_PAM, DEC_PIB_PDQ, and/or DEC_Validated_Parameters tests  are conducted with, or following this test, they will evaluated as described for those tests and the evaluation will be recorded for those tests.</p><p>NOTE: If the DEC_Interrupted_Communication test is conducted at this time, at least one message sent by the DOR for both patients will not have been received and the time manually recorded by the DOR for the interruption will be compared to the missing data point(s). That test should be accomplished for both partners. Note also that the data must be attributed to the correct patient. The evaluation will be recorded for that test. In addition: DORs that store and later send the missing data will pass if they show this is the case.</p><p>NOTE: If the DOR is capable of sending both validated and unvalidated messages that test may be conducted and evaluated at this time. For that test the DOR must partner with a DOC that can distinguish the two types of messages. That evaluation will be recorded for that test. That test need be accomplished only once.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (102, 1, 0, '2009-11-24 10:53:16.299', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This is the fundamental test for DEC systems, verifying the ability to send or receive multiple messages containing data for multiple physiological parameters for two or more patients. This test will apply with suitable assumptions if only a single patient is supported by a system. This test applies to sending and receiving systems that transmit multiple messages for the same patient or patients and may include messages for a vital signs monitor (VSM) or other device that sends messages for patients aperiodically &ndash; but only if the system supports continuous measurements as well. For a DOR system that transmits only one set of parameters for one or more patients (e.g., vital signs monitor) use test DEC_Vital_Signs_Monitor_RC or  DEC_Vital_Signs_Monitor_RFC instead.</p> <p>There are two variations of this test; be sure you select the right one(s):</p> <ul>     <li>DEC_One_to_One_Communication_RC </li>     <ul>      <li>DOR and a DOC </li>      <li>DOR with DOF in the same system, testing the DOR function and not the DOF; the DOC does not      use the query function to filter data </li>     </ul>     <li>DEC_One_to_One_Communication_RF</li>     <ul>      <li>Standalone DOF, testing the input side as if it were a DOC, will need a DOR as partner</li>     </ul> </ul> <p>NOTE: If the system is a DOF independent of a DOR, then the DOF must test as a DOC with a DOR (using DEC_One_to_One_Communication_RF). I.e., the DOF must receive messages from a DOR. Tests of its ability to respond to subscriptions from a DOC are provided elsewhere.  </p> <p>NOTE: Test names for this test are the same for DORs and DOFs. They play partner roles and DORs are responsible for coordinating with their partners <b>in advance of the Connectathon</b> to assure that the required number of receiving systems needed are able to receive the messages they will send.</p> <p>The DOR and DOF conduct the tests for all system types they support from this list: </p> <ul>     <li>Physiologic Monitor (bedside and/or perioperative monitors), </li>     <li>Vital Signs Monitor, </li>     <li>Infusion Pump, </li>     <li>Ventilator,</li>     <li>Other as developed with the Project Manager</li> </ul> <p>If, for example, a system supports bedside monitors and infusion pumps, messages will contain    parameters for parameter types within the bedside monitor (heart rate, blood pressure, etc.) and    for the pump.</p> <p>DORs will send, and DOFs will receive physiologic and/or pump parameters for two patients. If your system does not support multiple patients you need to make this known to your test partners and the project manager.</p> <p>RELATED TESTS:</p> <p>Developers may combine this test with:</p> <ul>     <li>DEC_Interrupted_Communication</li>     <li>PAM_ID_Mgmt</li>     <li>PDQ_Exact_Name and PDQ_Multiple_Query</li>     <li>DEC_Validated_Parameters (would follow this test)</li> </ul> <p> Please consult documentation for those tests, which are briefly summarized here:    DEC_Interrupted_Communication: Each system (except VSMs) must conduct one test of    DEC_Interrupted_Communication to show the ability to resume communications following an    interruption of the data link. Either or both systems may conduct that test after successful    communication of the minimum number of messages at this time, but they may not do so    simultaneously. </p> <p>PAM, PDQ: If the DOR supports either or both of the PAM and PDQ options in the Patient Identity    Binding (PIB) option, the DOR may elect to test either or both of these tests at this time by    using the PIB option to obtain the patient&rsquo;s demographics in conducting the    DEC_One_to_One_Communication. To obtain credit for either of both of these tests, conduct the    test consistent with that test.</p> <p>DEC_Validated_Parameters: If partners are available it may be an efficient use of time to    conduct this test after successfully conducting the DEC_One_to_One_Communication test. Refer to    that test for details. </p> </p><H3>Description</H3><p>A DOR sends a series of messages (as described in the tests listed below) to a DOF. Messages include multiple physiological parameters. Parameters should include sampled continuous parameters (e.g., heart rate) and relatively infrequently measured parameters (e.g., NIBP) if both are supported.</p><ol>     <li>DORs send at least three messages for each of two patients. Within the group of partners,     systems should test all system types they support (i.e., bedside, perioperative, vital signs     monitors; infusion pumps; ventilators). Each message will contain reasonable physiologic values     for at least six parameters for each system type (e.g., six or more for each patient&rsquo;s monitor     and six or more for each patient&rsquo;s pumps if both system types are supported). If the DOR     supports both validated and unvalidated data, this test is performed with unvalidated data. Each     message may include any number of additional parameters. If a system supports infrequent data     (e.g., NIBP), at least one instance of this data shall be sent in addition to the data types     sent in the other messages. Parameter values should be realistic for a patient in a cardiac ICU     bed or on an OR table.</li>     <li>Messages will alternate between the two patients. I.e., a message for patient #1 is followed     by a message for patient #2 before another message is sent for patient #1. Messages should not     be closer in time than 30 seconds apart.</li> </ol><p>If the system supports VSMs and other device types, then include one message (or message    sequence) from the VSM with one set data for multiple patients in this test. </p><p>Messages will alternate between patients (i.e., parameters for patient #1 are followed by    parameters for patient #2 before the next set of parameters are sent for patient #1). </p><p>Parameters should be sent from actual devices (preferred), simulators or, if necessary from    parameter tables provided by the Project Manager (least desirable).</p><p>PATIENT IDENTIFICATION:</p><p>For systems NOT using PAM or PDQ to obtain patient demographics, the patients for this test in    January 2008 are given below. Additional patients can be created using the same pattern.</p><table border="1" cellspacing="0" cellpadding="0">     <tr>      <td width="133" valign="top">       <p align="center">        <strong>System</strong>       </p>      </td>     <td width="91" valign="top">       <p align="center">        <strong>MRD</strong>       </p>      </td>     <td width="61" valign="top">       <p align="center">        <strong>First Name</strong>       </p>      </td>     <td width="67" valign="top">       <p align="center">        <strong>Last Name</strong>       </p>      </td>     <td width="127" valign="top">       <p align="center">        <strong>Location</strong>       </p>      </td>     <td width="79" valign="top">       <p align="center">        <strong>Mother&rsquo;s Maiden Name</strong>       </p>      </td>     <td width="73" valign="top">       <p align="center">        <strong>DOB</strong>       </p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; B Braun</p>      </td>     <td width="91" valign="top">       <p>BB2008001</p>      </td>     <td width="61" valign="top">       <p>Albert</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU - 31-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/61</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; B Braun</p>      </td>     <td width="91" valign="top">       <p>BB2008002</p>      </td>     <td width="61" valign="top">       <p>Charles</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/61</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Draeger (reporter)</p>      </td>     <td width="91" valign="top">       <p>DR2008001</p>      </td>     <td width="61" valign="top">       <p>Amy</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 32-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/62</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Draeger (reporter)</p>      </td>     <td width="91" valign="top">       <p>DR2008002</p>      </td>     <td width="61" valign="top">       <p>Carrie</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/62</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; GE (reporter)</p>      </td>     <td width="91" valign="top">       <p>GE2008001</p>      </td>     <td width="61" valign="top">       <p>Allen</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 33-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/63</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; GE (reporter)</p>      </td>     <td width="91" valign="top">       <p>GE2008002</p>      </td>     <td width="61" valign="top">       <p>Corey</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/63</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Philips (reporter)</p>      </td>     <td width="91" valign="top">       <p>PH2008001</p>      </td>     <td width="61" valign="top">       <p>Adrian</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 34-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/64</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Philips (reporter)</p>      </td>     <td width="91" valign="top">       <p>PH2008002</p>      </td>     <td width="61" valign="top">       <p>Connie</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/64</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Spacelabs </p>      </td>     <td width="91" valign="top">       <p>SP2008001</p>      </td>     <td width="61" valign="top">       <p>Arthur</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 35-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/65</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Spacelabs </p>      </td>     <td width="91" valign="top">       <p>SP2008002</p>      </td>     <td width="61" valign="top">       <p>Clark</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/65</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Welch Allyn</p>      </td>     <td width="91" valign="top">       <p>WA2008001</p>      </td>     <td width="61" valign="top">       <p>Andrea</p>      </td>     <td width="67" valign="top">       <p>Brooks</p>      </td>     <td width="127" valign="top">       <p>3 West ICU &ndash; 36-1</p>      </td>     <td width="79" valign="top">       <p>Coburn</p>      </td>     <td width="73" valign="top">       <p>1/1/66</p>      </td>     </tr>     <tr>      <td width="133" valign="top">       <p>&nbsp; Welch Allyn</p>      </td>     <td width="91" valign="top">       <p>WA2008002</p>      </td>     <td width="61" valign="top">       <p>Camille</p>      </td>     <td width="67" valign="top">       <p>Darwin</p>      </td>     <td width="127" valign="top">       <p>4 West ICU 32-1</p>      </td>     <td width="79" valign="top">       <p>Emerine</p>      </td>     <td width="73" valign="top">       <p>1/1/66</p>      </td>     </tr> </table><H3>Evaluation</H3><p>Project manager or monitor will observe the displays provided by the sending system and partner. The physiologic parameters and their measurement values, including the time of parameter measurement will be compared. The type of display/documentation by the receiving system is not constrained. The DOF need only be able to show success in receiving the data; the display need <b>not</b> be clinically useful.</p><p>Success: If the patients, the minimum number of parameters, the measurements and the time of measurement sent by the DOR matches those received by the DOF that will indicate the test has been successful. </p><p>NOTE: If DEC_Interrupted_Communication, PAM, PDQ, and/or DEC_Validated_Parameters tests  are conducted with, or following this test, they will evaluated as described for those tests and the evaluation will be recorded for those tests.</p><p>NOTE: If the DEC_Interrupted_Communication test is conducted at this time, at least one message sent by the DOR for both patients will not have been received and the time manually recorded by the DOR for the interruption will be compared to the missing data point(s). That test should be accomplished for both partners. Note also that the data must be attributed to the correct patient. The evaluation will be recorded for that test. In addition: DORs that store and later send the missing data will pass if they show this is the case.</p><p>NOTE: If the DOR is capable of sending both validated and unvalidated messages that test may be conducted and evaluated at this time. For that test the DOR must partner with a DOC that can distinguish the two types of messages. That evaluation will be recorded for that test. That test need be accomplished only once.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (103, 1, 0, '2009-11-24 10:53:16.302', 'epoiseau', '<h3>Description</h3> <p>While PCD-01 applies to device DORs not described above and to DOCs prepared to receive other parameters, the device must be described before specific tests can be determined as applicable to that device. Those interested in extending PCD-01 to other applications are encouraged to contact any of the cochairs of the Patient Care Device Domain.</p>  <h3>Evaluation</h3> <p>To be defined for the specific DOR</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (104, 1, 0, '2009-11-24 10:53:16.304', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This test addresses the ability of a DOR to integrate patient demographic information for two    patients with physiologic data. This test applies, with a note, if the DOR is capable only of    transmitting data for a single patient. If the DOR does not utilize the PIB option, do not    conduct this test.</p> <p>If both PAM and PDQ options are supported, this will be accomplished with one patient    identified via the DOR&rsquo;s database of prior PAM transmissions and the other via a query. If the    DOR supports only PAM or PDQ, both patients will be identified using the only appropriate option.    PAM or PDQ qualifying tests, if any, should be performed first.</p> <p>The user selects or validates the patient identification obtained and the DOR incorporates the    patient identity into the messages transmitted to a DOC.</p> <p> <b>Related Tests:</b> Developers may efficiently follow this test with either of these if    partners are available:</p> <ul>     <li>DEC_Interrupted_Communication_RC</li>     <li>DEC_Validated_Parameters_RC</li> </ul> </p><H3>Description</H3><p>Read DEC_One_to_One_Communication before proceeding.</p><p>DORs will send, and DOCs will receive, physiologic and/or pump parameters for two patients. If    your system does not support multiple patients you need to make this known to your test partners    and the project manager.</p><p>DORs will send at least three messages for each patient with reasonable physiologic values &ndash;    unless the DOR supports only Vital Signs Monitor (VSM) data. If VSM data is included, or is the    only data sent, the VSM sends one message with two or more patients&rsquo; data. If the DOR supports    both validated and unvalidated data, this test is performed with unvalidated data.</p><p>Messages will alternate between patients (i.e., parameters for patient #1 are followed by    parameters for patient #2 before the next set of parameters are sent for patient #1). </p><p>Parameters should be sent from actual devices (preferred), simulators or, if necessary from    parameter tables provided by the Project Manager (least desirable).</p><p>     <b>Patient Identification - TBD</b> </p><p>If this test is not combined with DEC_One_to_One_Communication, then each message shall contain    at least four parameters that the receiving DOF or DOC can process and display or document, and    may send any number of additional parameters. DORs are responsible for coordinating with their    partners in advance of the Connectathon to assure that partners are able to receive at least the    minimum four parameters required for a given test. Parameter values should be realistic for a    patient in a cardiac ICU bed or on an OR table.</p><p>If this test is combined with DEC_One_to_One_Communication, then follow the instructions for    the number and type of parameters found in that message.</p><H3>Evaluation</H3><p>Project manager or monitor will observe the displays provided by the DOR and partner DOC. The    physiologic parameters and their measurement values, including the time of parameter measurement    will be compared. The type of display/documentation by the DOC is not constrained, it need only    be clinically useful.</p><p>Success: If the patients, the minimum number of parameters, the measurements and the time of    measurement sent by the DOR matches those received by the DOC that will indicate the step in the    test has been successful. </p><p>NOTE: If this test is combined with, follows or is followed by another test they will be    evaluated separately.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (105, 1, 0, '2009-11-24 10:53:16.306', 'epoiseau', '<H3>Special Instructions</H3> <H3>Temporary Instructions - ignore references to DOFs. DOFs need to conduct DEC DOF PIB Unsuccessful Identification test</H3>  <p>This test addresses the ability of a DOR or DOF to function and identify a patient when the PIB option (PAM and/or PDQ) fails to provide patient demographic information for a patient. The DOR or DOF provide a secondary way to identify the patient and link that identification with the patient''s physiologic data. </p>  <p>If both PAM and PDQ options are supported, this will be accomplished by first attempting to obtain identification with PAM, and then with PDQ. That may be a manual or automatic attempt. </p>  <p><u>Related Tests: </u> Developers may efficiently integrate this test with DEC_With_PIB_Option and/or the appropriate one to one test: </p> <ul> <li>DEC_DOR_DOC_One_to_One_Communication_Periodic_Data</li> <li>DEC_DOR_DOC_One_to_One_Communication_Infrequent_Data  (data such as infusion pumps, NIBP devices or channels and beds) </li> </li> </ul>   <p>NOTE: While these test names include DOR and DOC, they apply to DOFs as well. </p>    <H3>Description</H3> <p>Conduct the appropriate one-to-one test and the DEC_With_PIB_Option test before proceeding. </p>  <p>The patient sought has the name Peter Rabbit. This patient''s demographics will not be sent in PAM messages, nor will it be in the ADT system''s database. </p>  <p>For PAM, this patient won''t be in the DOR''s database. For PDQ, query all as appropriate: </p> <ul> <li>Query by name. </li> <li>Query with location SICU room 1, bed 1. </li> <li>Query with MRN 1234. </li> </ul>   <p>When the attempt to identify the patient fails, the DOR may use any method it supports to provide sufficient patient identification to send three messages (or only one if the DOR or DOF supports data from devices sending only infrequent data). For example, if a hospital assigns temporary patient identification using the hospital name and a number (e.g., hospital name_sequential number), the DOR could use as temporary MRN: Hospital_DOR Name n, where Hospital is the facility identifier, DOR Name is the manufacturer''s name or DOR''s identification, followed by the number 1. </p>  <p>The user selects or validates the patient identification obtained and the DOR or DOF incorporates the patient identity into the messages transmitted to the DOC or DOF. </p>  <p>Sending systems will send at least three messages for each patient with reasonable values for four parameters assuming the patient is in an ICU or OR.  </p> <ul> <li>If the system only supports infrequent data (e.g., Vital Signs Monitor (VSM) or Non-Invasive Blood Pressure (NIBP) data then it will send two messages for at least two patients, with some change in parameter values in the second set of messages for each patient. </li> <li>If infrequent data is included with other data, the VSM or NIBP monitor need only send one message with one or more patients'' data. </li> <li>If the DOR supports both validated and unvalidated data, this test is performed with unvalidated data. </li> </ul>   <p>The sequence of messages is not important. </p>  <p>If the DOR supports both validated and unvalidated data, this test is performed with unvalidated data. </p>  <p>Parameter values should be realistic for a patient in a cardiac ICU bed or on an OR table. </p>  <p>Parameters should be sent from actual devices (preferred), simulators or, if necessary from parameter tables provided by the Project Manager (least desirable). </p>  <u>Patient Demographics</u> <p>Refer to the PCD_Patient_Demographics table and select two appropriate patients. </p>  <p>Developers are responsible for coordinating with their partners in advance of the Connectathon to assure that they will have the required number of partner systems that support the same physiologic or other parameters, with consistent coding. </p>  <H3>Evaluation</H3> <p>Project manager or monitor will observe the displays provided by the sending and receiving system(s). The patients'' names and/or medical record numbers (MRNs), physiologic and other parameters, their measurement values, and the time of parameter measurement/acquisition will be compared. The type of display/documentation by the receiving system is not constrained, it need only be clinically useful. </p>  <p>NOTE: If other tests are conducted with this test, they will evaluated as described for those tests and the evaluation will be recorded for those tests. </p>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (106, 1, 0, '2009-11-24 10:53:16.309', 'epoiseau', 'This test has been removed');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (107, 1, 0, '2009-11-24 10:53:16.313', 'epoiseau', '<h3>Special Notes</h3> <p>DEC_Physiological_Monitor is defined in the context of DOR/DOC pairs where the DOR is a Physiological Monitor. If your DOR is not a Physiological Monitor, do not perform this test.</p>  <p>This test does not apply to a monitor DOR that sends messages for patient or patients only once or intermittently (e.g., a vital signs monitor).</p>  <h3>Description</h3> <p>DORs will send messages with reasonable physiologic values for supported parameters. Each message shall contain the required number of parameters that the receiving DOC can process and display or document, and may send any number of additional parameters. DORs are responsible for coordinating with their DOC partners <em>in advance of the Connectathon</em> to assure that the DOCs are able to receive at least the minimum three parameters required for a given test. Parameter values should be realistic for a patient in a cardiac ICU bed or on an OR table. </p>  <p>At least four parameters will be be sent for each patient; at least three of which can be processed by the receiving DOC. Minimum parameters are selected from this list:  <ul>   <li>Heart or Pulse Rate</li>   <li>Electrocardiogram (various leads and lead identification); multiple leads together are counted as one in meeting the minimum of four parameters)</li>   <li>Temperature, and if supported, site</li>   <li>Non-invasive systolic and diastolic blood pressure, left arm</li>   <li>Invasive pressures (arterial, use right arm); arterial pressures together are counted once in meeting the minimum of four parameters)</li>   <li>SpO2</li>   <liLRespiration rate, and if supported respiration method, patient position</li>   <li>Weight, and if supported, method</li>   <li>Arrhythmia parameters</li>   <li>Intracranial pressure</li>   <li>Inspired and/or End-tidal CO2 pressure</li>   <li>Cardiac output</li>  </ul> </p>  <p>The number of messages sent in each step in the test is given above, in section 1.1, Test Items For DORs With Partner DOCs</p>   <h3>Evaluation</h3> <p>Project manager or monitor will observe the displays provided by the DOR and partner DOC. The physiologic parameters and their measurement values, including the time of parameter measurement will be compared. The type of display/documentation by the DOC is not constrained, it need only be clinically useful.</p>  <p>If the minimum number of parameters, measurements and time of measurement sent by the DOR matches those received by the DOC that will indicate the step in the test has been successful. NOTE: At least one message sent by the DOR for both patients will not have been received by the DOC (Communication Link Interrupted And Resumed) and the time recorded by the DOR for the interruption will be compared to the missing data point(s). Note also that the data must match the patient.</p>  ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (108, 1, 0, '2009-11-24 10:53:16.315', 'epoiseau', '<H3>Special Instructions</H3>  <p>This test applies to the SPD option. The option requires a DOC to query a DOF using the PCD-02 transactions. Then the sending DOF transmits, and the receiving DOC acquires, messages using the PCD-01 transactions. </p>  <p>This test applies to a</p> <ul> <li>DOF (as part of a DOR/DOF system and as a Standalone DOF) </li> <li>DOC that supports the SPD option. </li> </ul>  <p>Standalone DOFs must arrange for a DOR for data input. A Standalone DOF is a device/system that is not part of the device/system that contains the DOR, and that relies upon a separate DOR for patient data. </p>  <p>This test includes: </p> <ul> <li>Subscription for, and transmission of filtered data, filtering by location, </li> <li>Subscription for, and transmission of filtered data, filtering by MRN, </li> <li>Subscription for, and transmission of a snapshot of data, </li> <li>Subscription for parameters not in the system, </li> <li>Subscription for a patient (MRN) not in the system, and</li> <li>Subscription for a patient by location. </li> </ul>  <p>Data from the DOF should contain at least two parameters for each type of device the DOF system supports (e.g., bedside monitor with multiple parameters, infusion pump, VSM, NIBP).  If, for example, a system supports bedside monitors and ventilators, messages will contain 2 different parameters for parameter types within the bedside monitor (heart rate, invasive blood pressure, etc.) and for the ventilator. Parameters for each patient should differ in some easily recognizable way. </p>  <H3>Description</H3> <p>A DOC sends requests (subscriptions) for data filtered as described abpve. The DOF is not required to respond when the query is for parameters that are not supported. If it does respond it will be as agreed to by the partner systems since this is out of scope of the profile. </p>  <p>The ''failed'' subscription is followed with another subscription that can be met. This shows that the systems continue to function without any difficulty. </p>  <p>For data that can be supplied, the DOF sends a sufficient number of messages for each of the patients specified in the query to document successful transmission and receipt of the data. If the DOF supports both validated and unvalidated data, this test is performed with unvalidated data. Each message may include any number of additional parameters. </p>  <p>Parameter values should be realistic for a patient in a cardiac ICU bed or on an OR table. </p>  <p>When messages are sent for multiple patients the patients will be interleaved in some manner. I.e., a sufficient number of messages is sent for each patient to see that the DOR and DOC are capable of supporting multiple patients at the same time. Messages should not be closer in time than 30 seconds apart. </p>  <p>Parameters should be sent from actual devices (preferred), simulators or, if necessary from parameter tables provided by the Project Manager (least desirable). </p>  <u>Patient Demographics</u> Refer to the PCD_Patient_Demographics table and select two appropriate patients. </p>  <p>Developers are responsible for coordinating with their partners in advance of the Connectathon to assure that they will have the required number of partner systems that support the same physiologic or other parameters, with consistent coding. </p>  <H3>Evaluation</H3> <p>Project manager or monitor will observe the displays provided by the sending and receiving system(s). The patients'' names and/or medical record numbers (MRNs), physiologic and other parameters, their measurement values, and the time of parameter measurement/acquisition will be compared. The type of display/documentation by the receiving system is not constrained, it need only be clinically useful. </p>  <p>NOTE: If other tests are conducted with this test, they will evaluated as described for those tests and the evaluation will be recorded for those tests. </p>   ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (109, 1, 0, '2009-11-24 10:53:16.318', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This tests a DOF/DOC pair that implements the Subscribe to Patient Data (SPD) option. It    requires a cooperating DOR to send data to the DOF if the DOF is not contained within the same    system as the DOF. All DOR/DOC tests should be completed before testing the SPD option.</p> <p>There are two variations of this test; be sure you select the right one:</p> <ul>     <li>DEC_SPD_By_Location _FC (this is the test described here)</li>     <ul>      <li>DOR and DOF are contained in the same system; the DOR has succeeded with the DOR/DOC tests      where no subscription was required</li>     </ul>     <li>DEC_SPD_By_Location _RFC</li>     <ul>      <li>Standalone DOF, input to the DOF requires the DOF to act as a DOC, will need a DOR as      partner; the DOF has succeeded in testing as a DOC with a DOR to assure it can receive PCD-01      messages. </li>     </ul> </ul> <p>This tests the DOF&rsquo;s ability to receive and respond to a subscription request with the    appropriate filter and send the requested filtered data. It also tests the ability of the DOC to    subscribe and receive messages containing this filtered data. The test requires the DOC to    request multiple filtered messages containing data with multiple physiological parameters for two    or more patients (or only a single patient if multiple patients are not supported) and the DOF to    provide the data requested. If the DOF or DOR supports only Vital Signs Monitors (VSMs) , there    will be a single transmission with data from two or more patients in that transmission .</p> <p>Note 1: Test names are the same for DOFs and DOCs. They play partner roles. DOFs are    responsible for coordinating with their partners in advance of the Connectathon to assure that    the DOC needed is able to send or receive the messages.</p> <p>Note 2: Systems may use validated or unvalidated data</p> </p><H3>Description</H3><p>This test utilizes subscriptions and filtering based upon location. A DOC requests data as    described below. A DOF sends a series of messages in response. For efficiency, this test may be    conducted with multiple DOCs if supported, and if desired. </p><p> If multiple patients are supported by the DOF, this test will be conducted with two patients.    If either system does not support multiple patients, you must make this known to your test    partners and the project manager. If testing a DOF that supports only VSMs, please note the    differences below. </p><p>Messages include at least three physiological parameters for each type of system supported    (e.g., if the systems support bedside monitor and ventilator data, at least three parameters are    required for each). Parameters are selected at the discretion of the participating systems. The    DOF and the DOC will participate in sending or receiving messages for a variety of supported    parameter types; for this test, the DOF will send at least two messages at each step of this test    unless the test is solely for VSM data. The steps are:</p><ol>     <li>If the DOC is receiving messages it first sends a request to terminate all transmissions.</li>     <li>DOC (or DOCs) request messages for all available parameters for the patients in the table     below at a rate acceptable to the participating systems. At least one message is received for     each patient before proceeding. Patients are individualized for the DOF.</li>     <table border="1" cellspacing="0" cellpadding="0">      <tr>       <td width="120" valign="top">        <p>System</p>       </td>      <td width="90" valign="top">        <p>MRN</p>       </td>      <td width="60" valign="top">        <p>First Name</p>       </td>      <td width="66" valign="top">        <p>Last Name</p>       </td>      <td width="142" valign="top">        <p>Location</p>       </td>      <td width="79" valign="top">        <p>Mother&rsquo;s Maiden Name</p>       </td>      <td width="73" valign="top">        <p>DOB</p>       </td>      </tr>      <tr>       <td width="120" valign="top">        <p>&nbsp; B Braun (DOF)</p>       </td>      <td width="90" valign="top">        <p>BB2008001</p>       </td>      <td width="60" valign="top">        <p>Albert</p>       </td>      <td width="66" valign="top">        <p>Brooks</p>       </td>      <td width="142" valign="top">        <p>3 West ICU - 31-1</p>       </td>      <td width="79" valign="top">        <p>Coburn</p>       </td>      <td width="73" valign="top">        <p>1/1/61</p>       </td>      </tr>      <tr>       <td width="120" valign="top">        <p>&nbsp; B Braun (DOF)</p>       </td>      <td width="90" valign="top">        <p>BB2008007</p>       </td>      <td width="60" valign="top">        <p>Irma </p>       </td>      <td width="66" valign="top">        <p>Kwan</p>       </td>      <td width="142" valign="top">        <p>Emergency - ED4-2</p>       </td>      <td width="79" valign="top">        <p>Lee</p>       </td>      <td width="73" valign="top">        <p>1/1/62</p>       </td>      </tr>      <tr>       <td width="120" valign="top">        <p>&nbsp; Philips (DOF)</p>       </td>      <td width="90" valign="top">        <p>PH2008001</p>       </td>      <td width="60" valign="top">        <p>Adrian</p>       </td>      <td width="66" valign="top">        <p>Brooks</p>       </td>      <td width="142" valign="top">        <p>3 West ICU &ndash; 34-1</p>       </td>      <td width="79" valign="top">        <p>Coburn</p>       </td>      <td width="73" valign="top">        <p>1/1/64</p>       </td>      </tr>      <tr>       <td width="120" valign="top">        <p>&nbsp; Philips (DOF)</p>       </td>      <td width="90" valign="top">        <p>BB2008007</p>       </td>      <td width="60" valign="top">        <p>Ira</p>       </td>      <td width="66" valign="top">        <p>Kwan</p>       </td>      <td width="142" valign="top">        <p>Emergency - ED4-2</p>       </td>      <td width="79" valign="top">        <p>Lee</p>       </td>      <td width="73" valign="top">        <p>1/1/65</p>       </td>      </tr>      <tr>       <td width="120" valign="top">        <p>&nbsp; Spacelabs (DOF)</p>       </td>      <td width="90" valign="top">        <p>SP2008001</p>       </td>      <td width="60" valign="top">        <p>Arthur</p>       </td>      <td width="66" valign="top">        <p>Brooks</p>       </td>      <td width="142" valign="top">        <p>3 West ICU &ndash; 35-1</p>       </td>      <td width="79" valign="top">        <p>Coburn</p>       </td>      <td width="73" valign="top">        <p>1/1/65</p>       </td>      </tr>      <tr>       <td width="120" valign="top">        <p>&nbsp; Spacelabs (DOF)</p>       </td>      <td width="90" valign="top">        <p>BB2008007</p>       </td>      <td width="60" valign="top">        <p>Ima</p>       </td>      <td width="66" valign="top">        <p>Kwan</p>       </td>      <td width="142" valign="top">        <p>Emergency - ED4-2</p>       </td>      <td width="79" valign="top">        <p>Lee</p>       </td>      <td width="73" valign="top">        <p>1/1/66</p>       </td>      </tr>     </table>     <li>DOC #1 requests messages for the patient in the ICU and for the patient in the ER     corresponding to the DOF company&rsquo;s name. DOC #2 (if participating) does the same. The DOCs may     (but are not required to) request filtering on parameters to reduce the amount of data).</li>     <li>If the DOF will transmit VSM data, then one occurrence of that data is sent in addition to     any other data. The VSM will obtain data for two patients, each at least one minute apart in     time. The VSM will provide data to the DOR and combined DOF, in one connection, with data for     one patient sent immediately following data for the preceding patient. NOTE: The VSM will use     two patients on the ICU, and the subscription for the data will be for all patients on the ICU.</li>     <li>DOC(s) terminate the subscriptions. </li> </ol><H3>Evaluation</H3><p>Project manager or monitor will observe the displays provided by the DOF and DOC. The    physiologic parameters and their measurement values, including the time of parameter measurement    will be compared. The type of display/documentation by the DOF and DOC is not constrained, it    need only be clinically useful.</p><p>Success: If the patient, the minimum number of parameters, measurements and time of measurement    sent by the DOF matches those received by the DOC in each of the three steps above, that will    indicate the test has been successful. </p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (110, 1, 0, '2009-11-24 10:53:16.322', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This test applies  to DOCs that are able to receive messages from more than one DOF. In this test,  multiple DOFs send a series of messages for each patient to a DOC.</p> <p>This is a  scheduled test that follows one-to-one testing for the DOFs and DOCs. It  requires coordination among the partnering systems. This test verifies the  ability to receive multiple messages from multiple sending systems containing  data for multiple physiological parameters, each system sending data for two or  more patients (if supported). DOFs must coordinate their efforts and send a  sufficient number of messages so that the DOC receives at least two messages  from each sending system in a time interval that includes the other sending  systems. This test applies to gateways that transmit multiple messages for the  same patient or patients AND to a gateway that transmits only one set of  parameters for one or more patients (e.g., vital signs monitor).</p> <p>There  are three variations of this test; be sure you select the right one(s):</p> <ul>     <li>DEC_ SPD_One_to_Many _FC</li>      <ul>      <li>Two or more DOFs and one DOC,  testing the DOC&rsquo;s ability to support multiple DOFs</li>      <ul>       <li>DOF is part of the same system as  the associated DOR, testing the DOF function and not the DOR; the DOC uses the  query function to request filtered data </li>      </ul>     </ul>     <li>DEC_ SPD_One_to_Many _RFC</li>     <ul>      <li>Multiple standalone DOFs each  with a different collaborating DOR, testing the DOC&rsquo;s ability to support  multiple DOFs</li>     </ul>     <li>DEC_ SPD_One_to_Many _RFC_FC</li>     <ul>      <li>One or more standalone DOFs  alongside one or more DOR/DOF systems, testing the DOC&rsquo;s ability to support  multiple DOFs. The primary purpose for this test is to permit testing the DOC  when only two DOFs are available &ndash; one standalone and one DOR/DOF combination.  However, this test can be used with more DOF systems when the two types are present. </li>     </ul> </ul> <p>NOTE:  While standalone DOFs will conduct similar tests within DEC_Many_to_One_Communication, where the DOF receives  messages from multiple devices, a DOF in the same system as a DOR is presumed  to have this integration handled in the DOR portion of the system. If that is  not the case, then the DOF should test as a standalone DOF. A DOF standalone  system supporting multiple DORs must conduct also conduct the DEC_Many_to_One_Communication_RF  test if that function is supported. </p> <p>NOTE: Test names are the same for DORs, DOFs and  DOCs. They play partner roles and DOCs are responsible for coordinating with  their DOR/DOF partners <em>during the  Connectathon </em>to assure that the required number of sending systems that are  needed are able to send the messages they will receive.</p> </p><H3>Description</H3><p>Conduct DEC_One_to_One_Communication  test before proceeding.</p><p>DOFs that are part of DOR/DOF systems will send, and the DOC will receive  physiologic parameters for two patients from each DOF. If your system does not  support multiple patients you need to make this known to your test partners and  the project manager.</p><p>DOFs will send at least three messages for each of two patients in response to a subscription. The messages will include physiologic  data with reasonable values for at least three supported parameters. Parameters <strong><em>need  not</em></strong> include relatively infrequently measured parameters (e.g., NIBP).If the DOR supports both validated and  unvalidated data, this test is performed with unvalidated data. </p><ol>     <li>The  DOC terminates any subscriptions that may be active.</li>     <li>The  DOC subscribes to patient data from two or more DOFs that are available. The  DOC subscribes to at least four physiologic parameters that are available and  supported and supported from each. The patients available are unique to the DOR  associated with this DOF (see table below).</li>     <li>Two  or more DOFs, with whatever support they need from the associated DORs,  coordinate to send messages such that at least three messages are  near-simultaneously sent from each DOF to the same DOC(s).</li>     <ul>      <li>The  two DOFs may be sending different parameters; the parameters must be supported  by the DOFs and the DOC participating.</li>      <li>The  systems agree on the interval between messages so that the DOC(s) are tested  with the messages over the same time period. The interval between messages must  not be less than 30 seconds.</li>     </ul>         <li>The  DOCs terminate the subscriptions. </li> </ol><p>PATIENT IDENTIFICATION:</p><p>For systems NOT using PAM or PDQ to obtain patient demographics, the patients for this test in January 2008 are given below. Additional patients can be created using the same pattern.</p><table border="1" cellspacing="0" cellpadding="0">     <tr>      <td width="133" valign="top"> <p> <strong>System</strong> </p> </td>     <td width="91" valign="top"> <p> <strong>MRN</strong> </p> </td>     <td width="67" valign="top"> <p> <strong>First Name</strong> </p> </td>     <td width="61" valign="top"> <p> <strong>Last Name</strong> </p> </td>     <td width="127" valign="top"> <p> <strong>Location</strong> </p> </td>     <td width="79" valign="top"> <p> <strong>Mother&rsquo;s Maiden    Name</strong> </p> </td>     <td width="73" valign="top"> <p> <strong>DOB</strong> </p> </td>     </tr>     <tr>      <td width="133" valign="top"> <p>&nbsp; B Braun</p> </td>     <td width="91" valign="top"> <p>BB2008003</p> </td>     <td width="67" valign="top"> <p>Eddie</p> </td>     <td width="61" valign="top"> <p>Frank</p> </td>     <td width="127" valign="top"> <p>3 East ICU - 31-1</p> </td>     <td width="79" valign="top"> <p>Grant</p> </td>     <td width="73" valign="top"> <p>1/1/61</p> </td>     </tr>     <tr>      <td width="133" valign="top"> <p>&nbsp; B Braun</p> </td>     <td width="91" valign="top"> <p>BB2008004</p> </td>     <td width="67" valign="top"> <p>George</p> </td>     <td width="61" valign="top"> <p>Harris</p> </td>     <td width="127" valign="top"> <p>4 West ICU 31-1</p> </td>     <td width="79" valign="top"> <p>Ingram</p> </td>     <td width="73" valign="top"> <p>1/1/61</p> </td>     </tr>     <tr>      <td width="133" valign="top"> <p>&nbsp; Draeger (reporter)</p> </td>     <td width="91" valign="top"> <p>DR2008003</p> </td>     <td width="67" valign="top"> <p>Edie</p> </td>     <td width="61" valign="top"> <p>Frank</p> </td>     <td width="127" valign="top"> <p>3 East ICU &ndash; 32-1</p> </td>     <td width="79" valign="top"> <p>Grant</p> </td>     <td width="73" valign="top"> <p>1/1/62</p> </td>     </tr>     <tr>      <td width="133" valign="top"> <p>&nbsp; Draeger (reporter)</p> </td>     <td width="91" valign="top"> <p>DR2008004</p> </td>     <td width="67" valign="top"> <p>Glenda</p> </td>     <td width="61" valign="top"> <p>Harris</p> </td>     <td width="127" valign="top"> <p>4 West ICU 32-1</p> </td>     <td width="79" valign="top"> <p>Ingram</p> </td>     <td width="73" valign="top"> <p>1/1/62</p> </td>     </tr>     <tr>      <td width="133" valign="top"> <p>&nbsp; GE (reporter)</p> </td>     <td width="91" valign="top"> <p>GE2008003</p> </td>     <td width="67" valign="top"> <p>Ernie</p> </td>     <td width="61" valign="top"> <p>Frank</p> </td>     <td width="127" valign="top"> <p>3 East ICU &ndash; 33-1</p> </td>     <td width="79" valign="top"> <p>Grant</p> </td>     <td width="73" valign="top"> <p>1/1/63</p> </td>     </tr>     <tr>      <td width="133" valign="top"> <p>&nbsp; GE (reporter)</p> </td>     <td width="91" valign="top"> <p>GE2008004</p> </td>     <td width="67" valign="top"> <p>Glen</p> </td>     <td width="61" valign="top"> <p>Harris</p> </td>     <td width="127" valign="top"> <p>4 West ICU 33-1</p> </td>     <td width="79" valign="top"> <p>Ingram</p> </td>     <td width="73" valign="top"> <p>1/1/63</p> </td>     </tr>     <tr>      <td width="133" valign="top"> <p>&nbsp; Philips (reporter)</p> </td>     <td width="91" valign="top"> <p>PH2008002</p> </td>     <td width="67" valign="top"> <p>Ethel</p> </td>     <td width="61" valign="top"> <p>Frank</p> </td>     <td width="127" valign="top"> <p>3 East ICU &ndash; 34-1</p> </td>     <td width="79" valign="top"> <p>Grant</p> </td>     <td width="73" valign="top"> <p>1/1/64</p> </td>     </tr>     <tr>      <td width="133" valign="top"> <p>&nbsp; Philips (reporter)</p> </td>     <td width="91" valign="top"> <p>PH2008004</p> </td>     <td width="67" valign="top"> <p>Gert</p> </td>     <td width="61" valign="top"> <p>Harris</p> </td>     <td width="127" valign="top"> <p>4 West ICU 34-1</p> </td>     <td width="79" valign="top"> <p>Ingram</p> </td>     <td width="73" valign="top"> <p>1/1/64</p> </td>     </tr>     <tr>      <td width="133" valign="top"> <p>&nbsp; Spacelabs </p> </td>     <td width="91" valign="top"> <p>SP2008003</p> </td>     <td width="67" valign="top"> <p>Edward</p> </td>     <td width="61" valign="top"> <p>Frank</p> </td>     <td width="127" valign="top"> <p>3 East ICU &ndash; 35-1</p> </td>     <td width="79" valign="top"> <p>Grant</p> </td>     <td width="73" valign="top"> <p>1/1/65</p> </td>     </tr>     <tr>      <td width="133" valign="top"> <p>&nbsp; Spacelabs </p> </td>     <td width="91" valign="top"> <p>SP2008004</p> </td>     <td width="67" valign="top"> <p>Gary</p> </td>     <td width="61" valign="top"> <p>Harris</p> </td>     <td width="127" valign="top"> <p>4 West ICU 35-1</p> </td>     <td width="79" valign="top"> <p>Ingram</p> </td>     <td width="73" valign="top"> <p>1/1/65</p> </td>     </tr>     <tr>      <td width="133" valign="top"> <p>&nbsp; Welch Allyn</p> </td>     <td width="91" valign="top"> <p>WA2008002</p> </td>     <td width="67" valign="top"> <p>E.</p> </td>     <td width="61" valign="top"> <p>Frank</p> </td>     <td width="127" valign="top"> <p>3 East ICU &ndash; 36-1</p> </td>     <td width="79" valign="top"> <p>Grant</p> </td>     <td width="73" valign="top"> <p>1/1/66</p> </td>     </tr>     <tr>      <td width="133" valign="top"> <p>&nbsp; Welch Allyn</p> </td>     <td width="91" valign="top"> <p>WA2008004</p> </td>     <td width="67" valign="top"> <p>E.</p> </td>     <td width="61" valign="top"> <p>Harris</p> </td>     <td width="127" valign="top"> <p>4 West ICU 36-1</p> </td>     <td width="79" valign="top"> <p>Ingram</p> </td>     <td width="73" valign="top"> <p>1/1/66</p> </td>     </tr> </table><H3>Evaluation</H3><p>Project manager or monitor will observe the displays provided by the sending systems and partner receiver. The physiologic parameters and their measurement values, including the time the message is sent by the DOR or DOF, and time of receipt by the DOC will be compared. The type of display/documentation by the DOC is not constrained, it need only be clinically useful.</p><p>Success: If the patients, the minimum number and values of the parameters, and the time of measurement sent by the DOFs match those received by the DOC that will indicate the test has been successful. The two DOFs may be sending different parameters; the parameters must be supported by the DOFs and the DOC participating.</p> ');
INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (111, 1, 0, '2009-11-24 10:53:16.334', 'epoiseau', '<H3>Special Instructions</H3><p> <p>This tests a DOF/DOC pair that implements the  Subscribe to Patient Data (SPD) option. It requires a cooperating DOR to send  data to the DOF if the DOF is not contained within the same system as the DOF. All  DOR/DOC tests should be completed before testing the SPD option. This test is  NOT performed with data from Vital Signs Monitors.</p> <p>There  are two variations of this test; be sure you select the right one:</p> <ul>     <li>DEC_SPD_Snapshot _FC</li> </ul> <blockquote>     <p>DOR and DOF are contained in the  same system; the DOR has succeeded with the DOR/DOC tests where no subscription  was required</p> </blockquote> <ul>     <li>DEC_SPD_Snapshot _RFC</li> </ul> <blockquote>     <p>Standalone DOF, input to the DOF  requires the DOF to act as a DOC, will need a DOR as partner; the DOF has succeeded  in testing as a DOC with a DOR to assure it can receive PCD-01 messages.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </p> </blockquote> <p>This tests the  DOF&rsquo;s ability to receive and respond to a subscription request with the  appropriate filter and send the requested filtered data. It also tests the  ability of the DOC to subscribe and receive messages containing this filtered  data. The test requires the DOC to request multiple filtered messages  containing data with multiple physiological parameters for two or more patients  (or only a single patient if multiple patients are not supported) and the DOF  to provide the data requested. </p> <p>NOTE:  Test names are the same for DOFs and DOCs. They play partner roles. DOFs are  responsible for coordinating with their partners <em>in advance of the Connectathon</em> to assure that the DOC needed is  able to send or receive the messages.</p> <p>NOTE: Systems may use validated or unvalidated  data.</p> </p><H3>Description</H3><p>This test utilizes subscriptions and filtering to  achieve a single snapshot of data for each selected patient. </p><p>  The snapshot should include sampled continuous  data (e.g., heart rate at one value a minute) and data that is intermittent  (e.g., non-invasive blood pressure).</p><p>This test should precede the <strong>DEC_SPD_By_Location_FC</strong> test or follow the <strong>DEC_SPD_Unsupported_Parameters_FC</strong> test.</p><p>For efficiency, this test may be conducted with  multiple DOCs if supported, and if desired. </p><p>If multiple patients are supported by the DOF, this  test will be conducted with two patients. If either system does not support  multiple patients, you must make this known to your test partners and the  project manager. </p><p>A DOC requests  data as described below, and the DOF responds with the requested data. Messages  include at least three physiological parameters for each type of system  supported (e.g., if the systems support bedside monitor and ventilator data, at  least three parameters are required for each). Parameters are selected at the  discretion of the participating systems.. Parameters include sampled continuous  parameters (e.g., heart rate) and <em>should  include</em> relatively infrequently measured parameters (e.g., NIBP) if these  are supported. </p><p> The data source will send messages continuously  before and during each step of this test. The steps are:</p><ol>     <li>If  the DOC is receiving messages it first sends a request to terminate all  transmissions.</li>     <li>The  DOC requests only one set of data for each patient identified for the company.  The complete set for each patient may require more than one message in order to  obtain a snapshot of continuous data (e.g., a single value for heart rate) and  the next value for intermittent data (e.g., NIBP). If a second DOC is involved,  it should delay testing until the first DOC is finished its test.</li>     <li>DOC(s)  terminate the subscriptions.</li> </ol><table border="1" cellspacing="0" cellpadding="0">     <tr>      <td width="120" valign="top"> <p align="center"> <strong>System</strong> </p> </td>     <td width="90" valign="top"> <p align="center"> <strong>MRN</strong> </p> </td>     <td width="60" valign="top"> <p align="center"> <strong>First Name</strong> </p> </td>     <td width="66" valign="top"> <p align="center"> <strong>Last Name</strong> </p> </td>     <td width="142" valign="top"> <p align="center"> <strong>Location</strong> </p> </td>     <td width="79" valign="top"> <p align="center"> <strong>Mother&rsquo;s Maiden Name</strong> </p> </td>     <td width="73" valign="top"> <p align="center"> <strong>DOB</strong> </p> </td>     </tr>     <tr>      <td width="120" valign="top"> <p>&nbsp; B Braun (DOF)</p> </td>     <td width="90" valign="top"> <p>BB2008001</p> </td>     <td width="60" valign="top"> <p>Albert</p> </td>     <td width="66" valign="top"> <p>Brooks</p> </td>     <td width="142" valign="top"> <p>3 West ICU - 31-1</p> </td>     <td width="79" valign="top"> <p>Coburn</p> </td>     <td width="73" valign="top"> <p>1/1/61</p> </td>     </tr>     <tr>      <td width="120" valign="top"> <p>&nbsp; B Braun (DOF)</p> </td>     <td width="90" valign="top"> <p>BB2008007</p> </td>     <td width="60" valign="top"> <p>Irma </p> </td>     <td width="66" valign="top"> <p>Kwan</p> </td>     <td width="142" valign="top"> <p>Emergency - ED4-2</p> </td>     <td width="79" valign="top"> <p>Lee</p> </td>     <td width="73" valign="top"> <p>1/1/62</p> </td>     </tr>     <tr>      <td width="120" valign="top"> <p>&nbsp; Philips (DOF)</p> </td>     <td width="90" valign="top"> <p>PH2008001</p> </td>     <td width="60" valign="top"> <p>Adrian</p> </td>     <td width="66" valign="top"> <p>Brooks</p> </td>     <td width="142" valign="top"> <p>3 West ICU &ndash; 34-1</p> </td>     <td width="79" valign="top"> <p>Coburn</p> </td>     <td width="73" valign="top"> <p>1/1/64</p> </td>     </tr>     <tr>      <td width="120" valign="top"> <p>&nbsp; Philips (DOF)</p> </td>     <td width="90" valign="top"> <p>BB2008007</p> </td>     <td width="60" valign="top"> <p>Ira</p> </td>     <td width="66" valign="top"> <p>Kwan</p> </td>     <td width="142" valign="top"> <p>Emergency - ED4-2</p> </td>     <td width="79" valign="top"> <p>Lee</p> </td>     <td width="73" valign="top"> <p>1/1/65</p> </td>     </tr>     <tr>      <td width="120" valign="top"> <p>&nbsp; Spacelabs (DOF)</p> </td>     <td width="90" valign="top"> <p>SP2008001</p> </td>     <td width="60" valign="top"> <p>Arthur</p> </td>     <td width="66" valign="top"> <p>Brooks</p> </td>     <td width="142" valign="top"> <p>3 West ICU &ndash; 35-1</p> </td>     <td width="79" valign="top"> <p>Coburn</p> </td>     <td width="73" valign="top"> <p>1/1/65</p> </td>     </tr>     <tr>      <td width="120" valign="top"> <p>&nbsp; Spacelabs (DOF)</p> </td>     <td width="90" valign="top"> <p>BB2008007</p> </td>     <td width="60" valign="top"> <p>Ima</p> </td>     <td width="66" valign="top"> <p>Kwan</p> </td>     <td width="142" valign="top"> <p>Emergency - ED4-2</p> </td>     <td width="79" valign="top"> <p>Lee</p> </td>     <td width="73" valign="top"> <p>1/1/66</p> </td>     </tr> </table><H3>Evaluation</H3><p>Project manager or monitor will observe the displays provided by the DOF and DOC. The physiologic parameters and their measurement values, including the time of parameter measurement will be compared. The type of display/documentation by the DOF and DOC is not constrained, it need only be clinically useful.</p><p>Success: If the patient, the minimum number of parameters, measurements and time of measurement sent by the DOF matches those received by the DOC in each of the three steps above, that will indicate the test has been successful.</p> ');

INSERT INTO tm_test_description_aud (id, rev, revtype, last_changed, last_modifier_id, description) VALUES (113, 1, 0, '2009-11-24 10:53:16.341', 'epoiseau', '<H3>Special Instructions</H3><p> <p>DEC_Validated_Data_RC  is defined in the context of DOR/DOC pairs where the DOR and/or the DOC supports  validated messages or both validated and unvalidated messages. It also tests DOFs  to verify that they do not fail or compromise the validation indicator when  transmitting validation flags. Validation means the caregiver has reviewed the  results. </p> <ul>     <li>     If  the DOR is capable of sending only unvalidated data do not perform this test.     </li>     <li>     If  no DOC capable of distinguishing validated from unvalidated data is available,  do not perform this test.    </li>     <li>     If  the DOR is capable of sending validated data this test evaluates its ability to  send messages containing the validation flag and to support a DOC that can  distinguish the validation flag. If the DOR is capable of only sending  validated messages this test may be combined with the  DEC_One_to_One_Communication test.    </li> </ul> <p>NOTE: A DOC must succeed in accepting data with or  without the validation flag. A DOC capable of distinguishing validated/unvalidated  data should test against at least one DOR that sends validated messages and be  able to identify whether the validation is entered/not validated, or final. It  may also distinguish among other values for the flag. </p> <p>NOTE: This test can be coordinated with the One to  One Communication test.</p> <p>NOTE: This test need be performed only once for  DORs and for DOCs that support validated messages. These systems, however, may  be asked to conduct the test multiple times to satisfy other partners&rsquo; needs  for testing. </p> <p>There  are three variations of this test; be sure you select the right one:</p> <ul>     <li>DEC_ Validated _RC</li>     <ul>      <li>DOR and DOC; the DOR and the DOC  have succeeded with DEC_One_to_One_Communication </li>     </ul>         <li>DEC_ Validated _FC</li>     <ul>      <li>DOR and DOF are contained in the  same system; the DOR and DOC have succeeded with DEC_One_to_One_Communication </li>     </ul>         <li>DEC_SPD_ Validated _RFC</li>     <ul>      <li>Standalone DOF, input to the DOF  requires the DOF to act as a DOC, and will need a DOR as partner; the DOF has previously  succeeded in testing as a DOC with a DOR to assure it can receive PCD-01  messages.</li>     </ul>     </ul> <p>NOTE: Test names  are the same for all systems. They play partner roles. Developers of sending  systems are responsible for coordinating with their partners <em>in advance of the Connectathon</em> to assure that the receiving systems are able to receive <em>and preferably distinguish, validation of </em>at least the minimum  three physiologic parameters required for this test. Parameter values should be  realistic for a patient in a cardiac ICU bed or on an OR table. </p> </p><H3>Description</H3><p>Conduct DEC_One_to_One_Communication before proceeding.</p><p>DORs will send, and DOCs will receive physiologic parameters for any patient in a previous test. DOR will send validated data to a DOC that can distinguish validated data from unvalidated data. </p><p>NOTE: This test need be conducted only once to verify the ability to send or receive validated data.</p><H3>Evaluation</H3><p>Project manager or monitor will observe the displays provided by the sending system and partner. The physiologic parameters and their measurement values, including the time of parameter measurement will be compared. The type of display/documentation by the receiving system is not constrained, it need only be clinically useful.</p><p>Success: For the DOR, if there is evidence that validated data was sent, and for the DOC that validation was distinguished, and the patient, measurements and time of measurement sent matches those received, will indicate the test has been successful. </p> ');
