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