<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> 