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