TY - JOUR
AU - Tribble, Dennis, A.
AB - Pharmacies use a variety of computer-based systems (e.g., carousels, unit-based, automatic drug dispensing cabinets, robotic devices) with which manual entry of the same patient information repeatedly should be avoided. An interface is a communications process that allows information entered into one computer system (e.g., pharmacy information system [PIS]) to be shared with other systems.1 One type of interface is a print-stream interface, in which the PIS sends information to another computer-based system by pretending it is a printer. Print-stream interfaces were originally developed to facilitate the acquisition of data from large mainframe computer systems where the programming resources associated with those systems were overcommitted or too expensive to support a desired interface with another system. Print-stream interfaces were created with direct-wire connections to printers, which sometimes failed to reliably transfer information. Conventional wisdom holds that they are functionally inferior to more formal interface systems, such as Health Level 7. Specific concerns regarding these systems include their lack of a data-delivery-verification protocol, as well as concerns that changes in the format of the printed information may impair the ability of the receiving system to locate and extract the desired information. Print-stream interfaces offer potential advantages in situations where information is required from older systems that either cannot support more formal interfaces or in which the development of more formal interfaces is cost prohibitive or time prohibitive. These interfaces generally require work by only one party, the receiving system. Typically, the sending system is configured to treat the receiving system as if it were a printer and then sends reports or labels to that system as it would any other printer. This requires few, if any, changes in the sending system other than the designation of a new printer. Open in new tabDownload slide Open in new tabDownload slide All of the work to create and maintain the interface is the responsibility of the receiving system, which must implement rules by which it scans the printed information and locates and extracts data from the printed information. This means that interface development tends to occur more quickly because only one system is involved. Another advantage of the print-stream interface is that information is sent in a format that is intended to be printed on a printer. Therefore, if the interface experiences technical difficulties, the pharmacy can continue to work by simply sending the information to a different printer. For example, a pharmacy system may communicate with a robotic device by sending a set of labels to the robot which, in turn, extracts the information from those labels to prepare the medication orders for which those labels are intended. If this interface fails, the pharmacy can simply send exactly the same labels to a label printer and process the labels by hand. This type of recovery is considerably more difficult in a more formal interface structure. There are disadvantages to print-stream interfaces. These interfaces are strictly one-way interfaces. They cannot be used to transmit information back and forth between the interfaced systems (i.e., a bidirectional interface). In addition, print-stream interface data are generally limited to the data that were originally printed on the report or labels in the print stream. Since the labels are intended to be printed and used, it is unlikely that they will contain internal or external identifiers (e.g., national drug code [NDC] numbers) unless those data are included in a bar code. Moreover, changes to the label formatting can “break” the rules that “read” the label stream. Thus, changes to the format of a label used for such an interface must be planned carefully in consideration of the needs of the receiving system. Other formal interfaces use special interface programs to govern the sending and receiving of information in order to maintain a record of the actual receipt and acknowledgement of each transmission. In contrast, print-stream interfaces use the same queuing mechanism used by other printers to monitor the sending of information. It is therefore possible that the print stream will be received and acknowledged by the receiving computer system but will not actually be received by the intended application. This can lead to concerns about reliability. Concerns about the reliability of print-stream interfaces were raised when the interfaces primarily relied on older communication methods, such as serial communications. These communications could drop characters and change characters if the wires carrying them were too long or received electromagnetic interference (e.g., running across the ballast of a fluorescent light fixture) and required many verification steps (protocol) of the sending and receiving software to ensure the data were delivered intact. Since these applications were written as printer emulations, such a protocol was difficult to establish. The result was that a serial print job could be sent to a “printer” or printer emulator and lose characters or not be received at all, and the sending system was none the wiser. Modern printers use network connections that have such verification protocols built in as part of their communications hardware and software; they are considered to be reliable by definition. An example is Transport Control Protocol/Internet Protocol, the network communications used by the Internet.1 If a print job or any portion of a print job is not received and acknowledged by the “printer,” the print-queuing system acknowledges this failure as a “fail to print” and the print job remains in the queue. Further assurance can be gained by configuring a printer to operate the UNIX Line Printer Request/Line Printer Daemon (LPR/LPD) protocol. This protocol creates a conversation between the sending computer system and the receiving printer that requires the receiving printer to acknowledge successful receipt of the printed material before the sending system considers the printing job to be complete. Printed data are ultimately sent to printers as a series of lines of data containing embedded data (the information to be printed) and formatting commands (e.g., bolding, underlining, font size). Any data item can be located within lines at given positions. Modern software tools, such as regular expressions, can also be used to locate data based on the presence of key words or unique text patterns within the list of lines. For example, an i.v. label may always contain a patient identification (ID) number as a 10-digit number that follows the text “ID:.” A regular expression can locate this pattern even if its location on a label is inconsistent. This is especially useful when the print stream contains labels, because label formatting tends to be highly predictable and consistent. The print-stream interface identifies the beginning of each “label,” the array of lines that comprises that label, and then uses parsing rules to locate specified data on specified lines. Print streams intended for bar-code printers (e.g., Zebra, Intermec) are even easier to parse because they organize printed information into printable data fields that have a variety of attributes in addition to the data they contain that help locate and extract them. The printed fields may contain data that will be parsed into several different data fields (e.g., a field may contain both a patient name and room number), but once those fields are located, the extraction (parsing) of the individual fields tends to be quite easy to do. For example, observation of most i.v. room workflow readily reveals that the label for each medication dose serves as all the instruction necessary for a technician to prepare and for a pharmacist to check the prepared medication. Sending i.v. medication information to an automated i.v. preparation device lends itself well to be captured for printing, since the automated device, like the technician, requires the information on the label to know what and how much to prepare. Since drug names on labels are standardized within a formulary, they are generally as reliable as NDC numbers or other ID numbers in identifying the drugs to be used. Therefore, a list of medication doses to be prepared by an automated i.v. compounding device can be transmitted effectively from a PIS by simply printing the labels currently sent to the i.v. room label printer to the compounding device and building a database of doses to be prepared from the information on those labels, presuming the compounding device is configured for this use. The receiving software must have the capacity to (1) emulate the expected printer, (2) locate and extract information from the label stream, and (3) store the medication dose definition in a database of the receiving system. However, if critical information (e.g., actual dose, patient ID, rates of administration) is stored in comments entered by users during order entry or if the drug name as printed on the label can be modified by the person entering the order, that information cannot be considered to be reliable and the application of a print-stream interface is less desirable. Print-stream interfaces can be useful in specific, one-way interface applications when the cost and time of interface development would be quite high otherwise and when the information to be sent from one system to the other is already organized into discrete logical units, typically as labels or lines on a report. However, the interfaces require consistency in the printed presentation of information. Care must be taken to ensure that any changes in the printed format or content do not “break” the parsing rules for the print-emulation interface. References 1 Tribble DA. Overview of Transport Control Protocol/Internet Protocol communications. Am J Health-Syst Pharm . 2009 ; 66 : 446 –8. Crossref Search ADS PubMed Author notes The author has declared no potential conflicts of interest. The Informatics Interchange column gives readers an opportunity to share their experiences with information technology in pharmacy. AJHP readers are invited to submit their experiences and pertinent lessons-learned related to pharmacy informatics. Topics should focus on the use of information technology in the medication-use process, informatics pearls, informatics education and research, and information technology management. Readers are invited to submit their ideas or articles for the column to ajhp@ashp.org or AJHP, c/o Karl Gumpper at 7272 Wisconsin Avenue, Bethesda, MD 20814 (301-657-3000). Copyright © 2009, American Society of Health-System Pharmacists, Inc. All rights reserved.
TI - Print-stream interfaces
JF - American Journal of Health-System Pharmacy
DO - 10.2146/ajhp070593
DA - 2009-06-01
UR - https://www.deepdyve.com/lp/oxford-university-press/print-stream-interfaces-eopY1vAiUa
SP - 990
VL - 66
IS - 11
DP - DeepDyve
ER -