<H3>Special Instructions</H3>  <p>For this test, Clinician uses a BCMA that supports multiple pumps and multiple patients to initiate PCD-03 transactions consistent with the following steps. Vendors will document limitations if their BCMA does not support multiple pumps and multiple patients. </p>  <p>Clinician uses the BCMA Programmer to enter patient and pump identification and to identify the drug and the delivery parameters. Patient demographics are provided at the Kudu test page PCD_Patient_Demographics. Specific drug and parameters are given in the Kudu test page PIV_Parameter_Tables. </p>   <p>One IOP/IOC/pump system will demonstrate piggyback operation. If the IOP is not able to set the  piggyback flag that must be documented. If the IOC or pump do not support piggyback operation, document receipt of the piggyback flag and operation of a second channel on the pump. If a second channel is not available, another pump is used. </p>  <p>For the piggyback test, the IOP sets the piggyback flag. In 3.3.5.2.4, RXG - Pharmacy/Treatment Give Segment: RXR-4 includes 'This field identifies whether the infusion is to be administered as an IV piggyback or secondary infusion. When this is the case, the TF requires that this field be valued as IVPB.' </p>  <H3>Description</H3> <p>The pumps should run long enough to make it obvious that some fluid was delivered. If the IOP and IOC implement the DEC PCD-01 profile, that data may be used to help document what happened. An IOP receives pharmacy information or otherwise prepares to send a message (as described in the test steps provided below) to an IOC. Messages include multiple physiologic and/or operational parameters as appropriate for the IOC and pump channel(s) supported. </p>  <p>The test provides the steps required of both the IOP and IOC, playing partner roles. IOCs are responsible for coordinating with their partners in advance of the Connectathon to assure that the IOPs and IOCs will have the required number of systems needed for testing. It is necessary to determine that the partnering systems support at least several of 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>The IOP requests delivery of a third drug on the same patient using another pump. </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 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 IOP will use any two patients from the list developed with this process. </p>  <H3>Evaluation</H3> <p>Request a monitor validate performance.  Be prepared to demonstrate that the record of performance matches the record of the performance requested: the IOC received and, with support of the clinician, programmed the right pump to deliver the right drug, right amount, at the right flow rate via the right site to the right patient. If the IOP and IOC are capable of supporting the PCD-01 transactions that data may be used to help document performance. </p>  <p>Project manager or monitor will observe the displays provided by the sending and receiving system(s) and the pumps. The patients' names and/or medical record numbers (MRNs), physiologic and other parameters, their measurement values, and the time of parameter measurement/acquisition and receipt will be compared. The type of display/documentation by the receiving system is not constrained, it need only be clinically useful. </p> 