US20150205932A1 - Data transmission capture in support of medication preparation - Google Patents

Data transmission capture in support of medication preparation Download PDF

Info

Publication number
US20150205932A1
US20150205932A1 US14/577,855 US201414577855A US2015205932A1 US 20150205932 A1 US20150205932 A1 US 20150205932A1 US 201414577855 A US201414577855 A US 201414577855A US 2015205932 A1 US2015205932 A1 US 2015205932A1
Authority
US
United States
Prior art keywords
data
medication
order
automated
parsed
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US14/577,855
Inventor
Dennis Tribble
Joel A. Osborne
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Baxter Corp Englewood
Original Assignee
Baxter Corp Englewood
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=25536803&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=US20150205932(A1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Baxter Corp Englewood filed Critical Baxter Corp Englewood
Priority to US14/577,855 priority Critical patent/US20150205932A1/en
Assigned to FORHEALTH TECHNOLOGIES, INC. reassignment FORHEALTH TECHNOLOGIES, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: RASMUSSEN, RANDALL E., OLSEN, GREG, KHAN, ABDUL WAHID, OSBORNE, JOEL A., TRIBBLE, DENNIS, VALENTINE, MATTHEW
Assigned to BAXA-FHT, INC. reassignment BAXA-FHT, INC. MERGER (SEE DOCUMENT FOR DETAILS). Assignors: FORHEALTH TECHNOLOGIES, INC.
Assigned to BAXA CORPORATION reassignment BAXA CORPORATION MERGER (SEE DOCUMENT FOR DETAILS). Assignors: FHT, INC.
Assigned to FHT, INC. reassignment FHT, INC. CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: BAXA-FHT, INC.
Assigned to BAXTER CORPORATION ENGLEWOOD reassignment BAXTER CORPORATION ENGLEWOOD CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: BAXA CORPORATION
Priority to US14/734,944 priority patent/US20150278477A1/en
Publication of US20150205932A1 publication Critical patent/US20150205932A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • G06F19/3456
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/63ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for local operation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/17Details of further file system functions
    • G06F16/1734Details of monitoring file system events, e.g. by the use of hooks, filter drivers, logs
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2457Query processing with adaptation to user needs
    • G06F16/24573Query processing with adaptation to user needs using data annotations, e.g. user-defined metadata
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web
    • G06F16/951Indexing; Web crawling techniques
    • G06F17/30144
    • G06F17/30525
    • G06F17/30864
    • G06F19/322
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H20/00ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
    • G16H20/10ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99931Database or file accessing
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99931Database or file accessing
    • Y10S707/99933Query processing, i.e. searching

Definitions

  • the present invention relates to monitoring of data interfaces and network components and, more specifically, to data transmission capture that permits data configuration in support of medication preparation.
  • the invention can provide improvements in device interaction by initiating tasks in response to the receipt of data at a serial port that parse and manage the information in that data stream for handling by other network devices.
  • the invention can identify label data in a serial data stream and divide the label data into a first stream that launches automated medication preparation processes and a second stream that is redirected to a conventional printer.
  • data transmission between network components or locally to a network device can be monitored and processed regardless of format.
  • a method for selectively trapping data streams intended for a pharmacy comprises the steps of: trapping a printer output stream of an order entry system; parsing the output stream for prescribed information; testing the parsed output stream against an order database to determine suitability for automated handling by a medication preparation system associated with the pharmacy; and releasing only those portions of the output stream that are not suitable, the released output stream being printed for manual handling.
  • the foregoing method includes additional steps of populating a data structure with data parsed from the printer output stream in accordance with a set of configuration rules.
  • the printer output stream can identify its source so that the parsing step can parse the printer output stream in accordance with a set of configuration rules for that source.
  • the printer output stream is saved as a record or logged in a database.
  • metadata can be associated with the output stream to assist in further processing.
  • the metadata can identify the source of the printer output stream and include that source data for each record for use in parsing the printer output stream.
  • the metadata can also include a marker indicative of whether a given record has been parsed, with the marker being used in database queries to locate a subset of records that have been marked as not yet having been parsed.
  • the data in the record can be used to populate the data structure, as described above. It should be understood, however, that printer output streams and, more generally, serial data streams, can be managed by the methods of the present invention whether saved in a database or operated upon on the fly.
  • a serial data interface which comprises: at least one listener software module (“LSM”) executing on a first machine, the LSM receiving serial data streams from a port of the first machine; a parser software module (“PSM”) communicatively connectable to the LSM and executing on a second machine, the PSM processing the serial data streams received from the LSM to extract data therefrom and populate a data structure therewith; and a set of configuration rules accessible by the PSM, the set of configuration rules defining the manner of processing by the PSM on the serial data streams from a prescribed LSM, wherein the data structure enables data handling by an automated medication preparation system.
  • LSM listener software module
  • PSM parser software module
  • the PSM and LSM can execute on the same machine.
  • the serial data stream identifies a particular LSM and the set of configuration rules used for processing the serial data stream is selected for the identified LSM.
  • embodiments can save the received serial data streams as records in a database or operate on the data as it comes in over a port of the machine, and preferably utilize metadata of the type mentioned above and described more fully hereinbelow.
  • data transmissions of an order entry system for a pharmacy can be monitored and selectively processed.
  • Each data transmission can have an identifiable source.
  • the data transmissions are parsed in accordance with a set of configuration rules that can be associated with a particular source.
  • the parsed data is used to populate a data structure in further accordance with the configuration rules.
  • Suitability for automated handling by a pharmacy's medication preparation system is determined by comparing the parsed data stream against and order database. If the data stream is suitable for automated handling, the medication preparation system prepares one or more medications according to the data contained within the stream. If a portion of the data stream is not suitable for automated handling, that portion is released for manual handling.
  • the source of the data transmission can be determined and verified as a trusted or valid data source. If the source of the transmission is verified, then the data stream is processed to determine suitability for automated handling.
  • FIG. 1 is a functional block diagram of a software listener and parser module in accordance with an exemplary embodiment, and further illustrating its functional connections to a computer network.
  • FIG. 2 is a flow diagram illustrating the operation of an exemplary embodiment of a listener software module (LSM).
  • LSM listener software module
  • FIG. 3 is a flow diagram illustrating the operation of an exemplary embodiment of a parser software module (PSM).
  • PSM parser software module
  • FIG. 4 is a distributed hardware arrangement in which the PSM is responsive to multiple LSMs.
  • the present invention provides a software interface that enables a network device to emulate a printer that is attached to a network serial port in order to trap and filter serial data for automated handling by downstream equipment.
  • the interface exposes itself as a printer device that receives serial print strings, traps the data into a buffer or data store, parses the print string to extract data, and outputs the extracted data into a format usable by the network device.
  • the parsing routine is configurable to handle a variety of different data streams thereby permitting the interface to be used with standard networks and network devices without programming their respective output and input streams.
  • the serial interface is used to bridge a hospital information system to an automated medication preparation station.
  • the hospital information system in response to operator input or a program resident in that system, generates a stream of output data pre-configured to print onto labels. Ordinarily, this output stream is directed to a printer in a local or on-premises pharmacy and is used to prepare medications.
  • the label is thereafter applied to the preparation.
  • the preferred embodiment of the invention provides a configuration routine that permits an installer to configure a set of rules by which a parser software module (described below) locates the start and end of the data for each label, as well as discrete data elements within the label data.
  • the configuration routine thereby allows a user to configure messages that pass through the interface to be properly parsed for a given pharmacy system. Because users ordinarily can format labels for pharmacy systems as desired, both the structure of the incoming message to the pharmacy system and the rules for parsing these messages are field configurable, thereby providing great flexibility to the interface of the present invention.
  • both the listener and the parser are included on the same machine within an automated medication operation system to provide an interface to an order entry system (“OES”).
  • An exemplary automated medication operation is the PARxD IV medication preparation system of For Health Technologies, Inc., Oklahoma City, Okla., which prepares syringes for intravenous introduction.
  • An exemplary OES is the PharmNet Millennium hospital information system of Cerner Corporation, of Kansas City, Mo.
  • the PARxD IV is a software-controlled medical device that receives and manufactures orders for syringes for future (batch) or current (new order) production.
  • the PARxD IV device contains knowledge about how the syringes are to be prepared (final dose volume, diluents, etc.) and so the incoming order from the OES need only specify the drug and dose to be delivered, the patient name, the location of the patient, and other administrative information that may be of use to have on the syringe label.
  • FIG. 1 a functional block diagram of a software listener and parser module 100 is shown within an automated medication preparation system 110 that may be used within a pharmacy or other formulary.
  • an OES 120 located somewhere in the building sends new and batch orders for drugs to a label printer 130 over a serial data communication connection 140 .
  • the OES 120 has an RS- 232 serial port for one-way data communication over the link 140 to a standard printer 130 fitted with paper or, more typically, adhesive labels.
  • the automated system 110 is fitted with listener software, described below, that is preferably running resident in the automated system 110 , for example by being loaded into a memory 150 and executed by a central processing unit (“CPU) 160 .
  • the automated system 110 is connected directly or through a computer network to the serial port of the OES 120 through a one-way communication connection 170 .
  • the listener module manages data received across the connection 170 , for example, through a data bus 180 within the automated system 110 .
  • the serial data on connection 170 , the CPU 160 , the memory 150 and the listener module 100 are preferably all communicatively coupled to the data bus 180 .
  • the arrangement of FIG. 1 provides a listener module and a parser module together at the automated system 110 , but these modules can be resident in different machines, as described below in connection with the arrangement of FIG. 4 .
  • the parser module operates on the data received from the OES 120 to selectively cause the automated system 110 to manufacture drug dosages for administration to patients or to reject the data as not suitable for handling.
  • the parser can cause the automated system to prepare intravenous doses, oral doses, or doses suitable for specific therapies such as chemotherapy.
  • the automated system 110 is configured to prepare only one of these dosages types and so any dosage form outside the system's configuration (e.g., tablets) is rejected as not being suitable for handling.
  • Those drug orders that are not suitable are sent to the label printer 130 as a serial data output stream 190 . Consequently, the listener/parser module 100 enables drug orders to be better managed, with those susceptible to automated preparation being prepared without user intervention and with only those drug orders that are not suitable for the automated system 110 being sent to the label printer. This arrangement thereby reduces the number of drug orders that require manual handling, determines which orders require manual handling, and provides a filtered output stream 190 at the label printer 130 consisting of only those jobs that require manual handling.
  • the operation of the listener software module and the parser software module are described with reference to FIGS. 2 and 3 , respectively.
  • the listener software module opens a serial communications channel on a serial port of the automated system 110 at step 210 .
  • the listener module can be communicatively connected with the port making the connection 170 to the OES 120 .
  • the listener software module listens to that serial port for any data, at step 220 .
  • drug orders are preceded by a character or character string that marks the beginning of a serial data stream.
  • the LSM continuously tests to see whether a beginning-of-string character is detected at step 230 , because such character or string denotes the start of label data. If a beginning character is not detected, then the LSM loops back to the listening step 220 .
  • the serial data is written to a database together with (e.g., by appending) metadata.
  • the database assigns a unique transaction number, at step 240 , to a newly opened log entry or record that will contain the incoming serial data.
  • the LSM generates other data that is written to each log entry including the date and time of the transaction, the name assigned to the particular LSM that is writing the new database record, the serial data itself (sometimes referred to as “transaction text”), a marker to indicate whether the record requires parsing, a reference pointer that permits one database record to refer to another (e.g., for error checking purposes), and error condition information concerning errors that were observed on the communications line 170 during data transfer.
  • This information is assigned to the transaction at step 240 as well. All of this information can be reviewed, if desired, using a viewer that displays each log entry together with any error messages that might have been generated or associated with a particular database record.
  • the serial data itself is written to the record that was opened at step 240 .
  • the serial data continues to be written to that record until a label with an end-of-string character is detected or until a time-out event (e.g., end-of-message reached if no activity for X milliseconds) is detected, at step 260 .
  • a time-out event e.g., end-of-message reached if no activity for X milliseconds
  • one drug order can be distinguished from the next either by detecting a beginning-of-string character or by permitting a prescribed time period to pass since the last data came in.
  • the parser software module queries the database for any data that is to be parsed (i.e., data records that are marked as requiring parsing).
  • the LSM engrafts metadata to the serial stream coming into the automated system 110 over the connection 170 .
  • An index can be used to speed query processing, as understood by those of skill in the art.
  • the PSM uses the marker to determine which records have not been parsed, and returns a list of the labels that still must be parsed in order to fill all the drug orders (whether new or batch).
  • a record is retrieved at step 310 and parsed by the PSM at step 315 . Parsing is conducted in accordance with configuration rules that have previously been established for that LSM.
  • the configuration rules can accommodate a variety of data formats including fixed formats, name-value pairs, and XML formats.
  • the drug order data will have prescribed positions within the serial data stream such as a patient name occupying character positions 15-45 on the fourth line of the label or positions 15-45 on the same line of the label as the word “patient.”
  • the serial data is in the name—value pair format, the data may be located between a variable delimiter (“ ⁇ Patient>”) and an end-of-line character (e.g., CR, LF or both).
  • ⁇ Patient> an end-of-line character
  • the particular LSM is preferably identified in the data record, multiple data formats can be accommodated by the PSM and properly parsed by selecting a suitable set of configuration rules. A set of configuration rules, therefore, enables proper parsing of the data from the printer output stream into the data structure used by the PSM to determine suitability for handling and handling of drug orders by the automated medication preparation system.
  • a distributed system 400 is illustrated in which the automated system 410 comprises the PARxD IV drug preparation system of For Health Technologies, Inc.
  • the system 410 has a parser software module 415 executing as a resident software application on one machine.
  • the OESes 420 A, 420 B also comprise physically distinct systems, such as an in-patient system and an outpatient system configured to service different patient sets.
  • Each OES has its own LSM 425 A, 425 B, respectively, which writes data records having uniquely assigned transaction numbers to a database 435 .
  • OES 425 A and 425 B can have different data formats, yet because each new data record identifies the source of the record (L1 or L2), the parser 415 can properly parse records as they are retrieved at step 315 .
  • a test is made at step 320 to determine whether the data received from the OES was received correctly. For example, the test can ensure that the checksum was valid and check its type (Mod 43, 16-bit cycle redundancy check (“CRC”), 32 bit CRC, etc.). If the data entered into the data record did not write correctly, the error is written to the database at step 325 , for example as a new log entry, and the next database record in the list is retrieved at step 360 .
  • the new log entry preferably includes a reference pointer back to the log entry that had the error.
  • the transaction data is populated into a data structure at step 330 .
  • the data structure is selected to be compatible with the automated system 110 , 410 and serves to assign each of the required data values with a variable.
  • the variables that are included in the data structure can include, but are not limited to: the patient's name, location within the hospital or other institution, a drug code (e.g., the national drug code (“NDC”), the drug named in the drug order, the dose, the units, the administration date, the administration time, the order date, the order time, the checksum, any label comments, the order type (e.g. batch or new), and order frequency (e.g. “q6h6,” for every six hours starting at 6 A.M.).
  • NDC national drug code
  • the drug order is tested at step 335 by the parser to see whether it is suitable for handling by the automated system.
  • a given drug order is generally suitable for handling unless one of the following limited circumstances exists:
  • the test at step 335 should result in a determination that the drug order can be handled by the automated system.
  • the test for suitability for handling is made with reference to an order database that maintains tables of data concerning drug names and drug codes associated with those names in various dosages.
  • the next step 340 the drug order is forwarded to the label printer 130 for printing (e.g., onto an adhesive label) and manual handling by staff. If, however, the test that step 335 resulted in the determination that the drug order can be handled by the automated system, then the populated data structure is forwarded to the automated system for handling at step 345 .
  • the data structure can first be routed to a scheduler for queue handling in accordance with a prescribed priority. For example, a new order can be processed ahead of a batch order if the prescribed priority is “whether time permits” such routing.
  • the step of determining whether the drug order is suitable for handling results in the drug order being automatically processed or, if not automatically processed, a label being generated for only those drug orders that cannot be automatically processed. This results in proactive and dynamic filtering of drug orders as they come in over serial data lines from order entry systems, in view of the capabilities of the automated systems and their current stock of medications.
  • a test is made to determine whether there are any more listed records to retrieve in response to the database query at step 305 . If there are no more records to retrieve, the process ends at step 355 . Otherwise, if there are more records, the next record is retrieved at step 360 and the process flow loops back to step 315 where the newly retrieved record is parsed in accordance with the configuration rules for the listener that created that record.
  • the PSM may return several different errors, each of which is preferably recorded as a log entry in the database.
  • steps 315 , 320 , and 330 are marked with an asterisk (“*”) to indicate the steps at which errors might be returned.
  • an error code could result at step 315 .
  • the checksum test at step 320 determines that the checksum is missing or does not match, an error code results and is written to the error log at step 325 .
  • the parser will determine this when populating the data structure with the transaction data, at step 330 .
  • a reference pointer to the problematic data record is preferably included whenever appropriate.
  • a reference pointer is not appropriate, for example, when the error concerns a failure of the serial port or other hardware error.
  • the one-way serial listener interface lacks hand-shaking to permit confirmation that all information has been received intact from the OES.
  • a more robust protocol such as HL7 over TCP/IP using a minimal lower layer protocol can be used, if necessary, to provide such confirmations.
  • the LSM is designed to trap a serial output stream of the type that is ordinarily sent to a label printer.
  • This output stream is in the clear, that is, is non-proprietary, and includes critical information for preparing a medication.
  • the automated system can ensures compatibility with any hospital information system.
  • the present invention also can be used to monitor or listen to many varying types of network data transmissions between and among network components or to monitor data transmissions stored locally within a networked component regardless of whether the data is transmitted as serial data or to a serial port.
  • the invention can be adapted to capture, process, and automate the handling and preparation of medications using systems that are at least partially paperless or do not rely on printers for order management and fulfillment.
  • the invention can be adapted for use within an OES 120 that is not directed specifically to the printing of medication labels, but which more broadly is configured to manage the transmission and processing of medication orders, such as within or to a pharmacy.
  • Data transmissions can be monitored between and among devices in communication over a network. Monitoring can be performed by the LSM between various network devices including similar devices (e.g., between computers) or between a dissimilar devices (e.g., computer and a networked printer).
  • data transmission can be monitored by a standalone network LSM positioned within a network to intercept or “sniff” (e.g., receive without affecting the data being transmitted) network communications. If a standalone component is used, it can be configured to relay suitable medication orders to a separate automated system 110 .
  • the LSM can include software executing on one of the networked devices (e.g., the automated system 110 ).
  • monitoring software can be programmed into the network protocol stack of a network device so as to intercept data transmissions when received, or after being received, by the device.
  • Data transmissions can be intercepted covertly such that the application intended to receive the communication is unaware of the interception, or, alternatively, the data transmission interception can be known or publicized to other components in the system.
  • the LSM can include an email filter configured to monitor incoming email or monitor email contained in a specific set of folders. Monitored email messages can be parsed by the PSM to extract the data necessary to fulfill medication orders.
  • an email program monitors email messages when or after they are received. The email message is parsed by the PSM and tested to determine if it is suitable for handling by the automated medication preparation system 110 . If the data contained within the message cannot be handled by the automated medication preparation system 110 , it is released to be handled by the email program in the ordinary manner in which such messages are handled (e.g., forwarded to a specific email address for manual processing).
  • the LSM can include a software program configured to receive instant messages (e.g., AIM, Jabber, Yahoo Messenger, and ICQ) and/or monitor instant messages sent to a specific user for processing at a pharmacy. Monitoring can be performed in a manner similar to the monitoring of email as discussed above, with messages received by the IM software being parsed when or after they are received.
  • an automated instant messaging software program (“bot”) can be configured to act as the destination of messages containing medication order information.
  • the bot can act as the destination (e.g., the interface to the automated system 110 ), or alternatively can act as an intermediary that receives and distributes messages suitable for automated handling to the automated medication preparation system 110 and forwards messages that are not suitable for automated handling to a manual handling destination.
  • the destination e.g., the interface to the automated system 110
  • the bot can act as the destination (e.g., the interface to the automated system 110 ), or alternatively can act as an intermediary that receives and distributes messages suitable for automated handling to the automated medication preparation system 110 and forwards messages that are not suitable for automated handling to a manual handling destination.
  • Data transmissions that are stored on a computer can be actively monitored by a software process.
  • the process can poll a specific directory for new messages that contain data concerning medication orders. If a new file is present, the file can be processed in the above described manner thereby causing those portions of orders suitable for automated handling to be fulfilled by an automated medication preparation system and relaying the portions of orders not suitable for automated handling to a specified destination for manual fulfillment.
  • FTP File Transfer Protocol
  • An order that is not suitable for automated handling can be forwarded to a specified destination for manual order fulfillment.
  • the portions of a data transmissions that are unsuitable for automated processing are forwarded to a printer.
  • those portions of orders can be relayed in their original format, or transformed into a new format.
  • medication orders contained in a file on a networked disk drive that are unsuitable for automated handling can be converted into an email and sent to the appropriate address for manual fulfillment within the pharmacy.
  • LSMs can exist at a variety of locations throughout the system.
  • a particular LSM can listen to all data transmissions it receives, or it can be associated with a particular source or destination.
  • the LSM can process all information it receives or filter the received data transmissions for its associated source or destination.
  • multiple PSMs can coexist within the environment.
  • Each PSM can be associated with a particular medication preparation station (e.g., I.V. station or syringe station), and receive data transmissions designated for that station from one or more LSMs.
  • PSMs can receive data transmissions from one or more LSMs and determine the designated medication preparation station after parsing the information.
  • the invention can capture data transmissions in a variety of formats from a variety of sources, and distribute the information contained within the data transmissions to multiple machines configured to perform different tasks.
  • each transmission can be associated with the particular source from which it was sent.
  • Each source can identify itself during data transmission or include its identity in the transmission.
  • the system monitoring the information can record the source of the message. For example, if the messages are transmitted using a TCP/IP packet, the IP address of the source can be logged and associated with the transmission.
  • source identification can be used alone or in combination.
  • email messages and instant messages identify the sender of the transmission.
  • Further source identification can be accomplished by signing the data transmissions.
  • cryptographic keys can be associated with the machines sending messages. These keys can be used sign outgoing messages such that the sender can be authenticated without further human action to authenticate the message.
  • the source of the data transmission identified is authenticated by the automated system 110 as a valid source.
  • Valid source ID's can be stored in the database 435 and compared with the source of the transmission.
  • data transmissions that are signed can be authenticated through the user of a secure key server (not shown).
  • the further processing of the data transmission can be predicated on the successful authentication of the source as a valid source.
  • the transmission can be logged, for example in the database 435 , and stored with the determined source for future analysis or processing.
  • each data transmission can be logged whether the source is determined valid or invalid.
  • the transmission can be logged in the database 435 , flat file, or by any other standard method known in the art.
  • Various metadata and derivative data determined from analyzing the data transmission can be also be logged and associated with the logged data transmission. For example, the determined data source, parsed data, or any errors encountered while authenticating the source or parsing the data can be logged. Entries in the log that include errors can be flagged for analysis manually or by secondary systems.
  • the log, or portions of the log can also be displayed to a user or printed for review. Additionally, the log can be filtered and searched to generate reports based on various criteria or to enable a user to find a specific set of entries.

Abstract

A method and software interface enables selective processing of data transmissions containing one or more medication orders intended for a pharmacy. Data transmissions are monitored and parsed for prescribed information which is utilized to populate a prescribed data structure, The data structure and parsing rules can be associated with a specific source that can be determined from the data transmission. The parsed data is tested against an order database to determine suitability for automated handling. If suitable, the medication preparation system prepares the medications identified by the data. Those portions of the data that are not suited for automated handling are released (e.g., from the parser). Further verification can be performed by determining the source of the data transmission and verifying it as a valid source, Data transmissions can be monitored over a network, within a network component, or in cooperation with another software program.

Description

  • This application is a continuation-in-part of U.S. patent application Ser. No. 09/991,048 entitled “Serial Data Capture Processing,” U.S. Pat. No. 7,096,212, which is hereby incorporated by reference.
  • FIELD OF THE INVENTION
  • The present invention relates to monitoring of data interfaces and network components and, more specifically, to data transmission capture that permits data configuration in support of medication preparation.
  • BACKGROUND OF THE INVENTION
  • The task of integrating multiple systems into a computer network is often associated with custom programming and delays. This is particularly true when dealing with proprietary network components such as may often be found in hospital environments. For example, hospital information systems are conventionally employed to manage patient data and input medications that are to be administered to a patent. An electronic hospital information system typically must interact with an electronic pharmacy system within an automated facility, the interface between these two systems requires that the software communicate and process the data appropriately. When integrating a new network component into an existing system, the software providers of each system must meet and agree upon specifications prior to even establishing a project timetable, in order to ensure that the necessary communications and processing needs are met. This is attendant with great expense and difficulty.
  • On the other hand, most hospital information systems and pharmacy systems send data to label printers that identify a patient, a medication to be administered, the time of administration, contra-indications, and other data. It makes no difference whether the label printer is a local or network device. Thus, one way of obtaining a reliable data stream from one system for importing into another is to capture the data that is intended to be printed to a label. However, in order to operate on this data, subsequent processing is required. The electronic transmission of data through hospitals has resulted in the integration on various messaging systems, data storage, and order processing. In some environments, a printed label may not be generated from an order. Rather, the order can remain in an electronic format.
  • The invention can provide improvements in device interaction by initiating tasks in response to the receipt of data at a serial port that parse and manage the information in that data stream for handling by other network devices. In further aspects, the invention can identify label data in a serial data stream and divide the label data into a first stream that launches automated medication preparation processes and a second stream that is redirected to a conventional printer. According to yet a further aspect of the invention, data transmission between network components or locally to a network device can be monitored and processed regardless of format.
  • SUMMARY OF THE INVENTION
  • In accordance with one aspect of the invention, a method for selectively trapping data streams intended for a pharmacy comprises the steps of: trapping a printer output stream of an order entry system; parsing the output stream for prescribed information; testing the parsed output stream against an order database to determine suitability for automated handling by a medication preparation system associated with the pharmacy; and releasing only those portions of the output stream that are not suitable, the released output stream being printed for manual handling.
  • In a particular embodiment of the invention, the foregoing method includes additional steps of populating a data structure with data parsed from the printer output stream in accordance with a set of configuration rules. In another embodiment, the printer output stream can identify its source so that the parsing step can parse the printer output stream in accordance with a set of configuration rules for that source. In a particularly preferred embodiment, the printer output stream is saved as a record or logged in a database. In this preferred method, metadata can be associated with the output stream to assist in further processing. Thus, for example, the metadata can identify the source of the printer output stream and include that source data for each record for use in parsing the printer output stream. The metadata can also include a marker indicative of whether a given record has been parsed, with the marker being used in database queries to locate a subset of records that have been marked as not yet having been parsed. The data in the record can be used to populate the data structure, as described above. It should be understood, however, that printer output streams and, more generally, serial data streams, can be managed by the methods of the present invention whether saved in a database or operated upon on the fly.
  • In accordance with another aspect of the present invention, a serial data interface is provided which comprises: at least one listener software module (“LSM”) executing on a first machine, the LSM receiving serial data streams from a port of the first machine; a parser software module (“PSM”) communicatively connectable to the LSM and executing on a second machine, the PSM processing the serial data streams received from the LSM to extract data therefrom and populate a data structure therewith; and a set of configuration rules accessible by the PSM, the set of configuration rules defining the manner of processing by the PSM on the serial data streams from a prescribed LSM, wherein the data structure enables data handling by an automated medication preparation system.
  • Depending on the complexity or needs of a given implementation, the PSM and LSM can execute on the same machine. In a preferred embodiment, the serial data stream identifies a particular LSM and the set of configuration rules used for processing the serial data stream is selected for the identified LSM. As in the method above, embodiments can save the received serial data streams as records in a database or operate on the data as it comes in over a port of the machine, and preferably utilize metadata of the type mentioned above and described more fully hereinbelow.
  • In accordance with yet a further aspect of the present invention, data transmissions of an order entry system for a pharmacy can be monitored and selectively processed. Each data transmission can have an identifiable source. The data transmissions are parsed in accordance with a set of configuration rules that can be associated with a particular source. The parsed data is used to populate a data structure in further accordance with the configuration rules. Suitability for automated handling by a pharmacy's medication preparation system is determined by comparing the parsed data stream against and order database. If the data stream is suitable for automated handling, the medication preparation system prepares one or more medications according to the data contained within the stream. If a portion of the data stream is not suitable for automated handling, that portion is released for manual handling.
  • In accordance with further features of the present invention, the source of the data transmission can be determined and verified as a trusted or valid data source. If the source of the transmission is verified, then the data stream is processed to determine suitability for automated handling.
  • These and other aspects, features, steps and advantages can be appreciated further from the accompanying Drawing Figures and Detailed Description of Certain Embodiments.
  • BRIEF DESCRIPTION OF THE DRAWING FIGURES
  • FIG. 1 is a functional block diagram of a software listener and parser module in accordance with an exemplary embodiment, and further illustrating its functional connections to a computer network.
  • FIG. 2 is a flow diagram illustrating the operation of an exemplary embodiment of a listener software module (LSM).
  • FIG. 3 is a flow diagram illustrating the operation of an exemplary embodiment of a parser software module (PSM).
  • FIG. 4 is a distributed hardware arrangement in which the PSM is responsive to multiple LSMs.
  • DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS
  • By way of overview and introduction, the present invention provides a software interface that enables a network device to emulate a printer that is attached to a network serial port in order to trap and filter serial data for automated handling by downstream equipment. Externally, the interface exposes itself as a printer device that receives serial print strings, traps the data into a buffer or data store, parses the print string to extract data, and outputs the extracted data into a format usable by the network device. Preferably, the parsing routine is configurable to handle a variety of different data streams thereby permitting the interface to be used with standard networks and network devices without programming their respective output and input streams.
  • In a preferred implementation, the serial interface is used to bridge a hospital information system to an automated medication preparation station. The hospital information system, in response to operator input or a program resident in that system, generates a stream of output data pre-configured to print onto labels. Ordinarily, this output stream is directed to a printer in a local or on-premises pharmacy and is used to prepare medications. The label is thereafter applied to the preparation. The preferred embodiment of the invention provides a configuration routine that permits an installer to configure a set of rules by which a parser software module (described below) locates the start and end of the data for each label, as well as discrete data elements within the label data. The configuration routine thereby allows a user to configure messages that pass through the interface to be properly parsed for a given pharmacy system. Because users ordinarily can format labels for pharmacy systems as desired, both the structure of the incoming message to the pharmacy system and the rules for parsing these messages are field configurable, thereby providing great flexibility to the interface of the present invention.
  • In the preferred implementation, both the listener and the parser are included on the same machine within an automated medication operation system to provide an interface to an order entry system (“OES”). An exemplary automated medication operation is the PARxD IV medication preparation system of For Health Technologies, Inc., Oklahoma City, Okla., which prepares syringes for intravenous introduction. An exemplary OES is the PharmNet Millennium hospital information system of Cerner Corporation, of Kansas City, Mo. The PARxD IV is a software-controlled medical device that receives and manufactures orders for syringes for future (batch) or current (new order) production. The PARxD IV device contains knowledge about how the syringes are to be prepared (final dose volume, diluents, etc.) and so the incoming order from the OES need only specify the drug and dose to be delivered, the patient name, the location of the patient, and other administrative information that may be of use to have on the syringe label.
  • With reference now to FIG. 1, a functional block diagram of a software listener and parser module 100 is shown within an automated medication preparation system 110 that may be used within a pharmacy or other formulary. In conventional pharmacies in which the automated system 110 is not present, an OES 120 located somewhere in the building sends new and batch orders for drugs to a label printer 130 over a serial data communication connection 140. For example, the OES 120 has an RS-232 serial port for one-way data communication over the link 140 to a standard printer 130 fitted with paper or, more typically, adhesive labels. However, in accordance with the present invention, the automated system 110 is fitted with listener software, described below, that is preferably running resident in the automated system 110, for example by being loaded into a memory 150 and executed by a central processing unit (“CPU) 160. The automated system 110 is connected directly or through a computer network to the serial port of the OES 120 through a one-way communication connection 170. The listener module manages data received across the connection 170, for example, through a data bus 180 within the automated system 110. The serial data on connection 170, the CPU 160, the memory 150 and the listener module 100 are preferably all communicatively coupled to the data bus 180.
  • The arrangement of FIG. 1 provides a listener module and a parser module together at the automated system 110, but these modules can be resident in different machines, as described below in connection with the arrangement of FIG. 4. The parser module operates on the data received from the OES 120 to selectively cause the automated system 110 to manufacture drug dosages for administration to patients or to reject the data as not suitable for handling. Thus, depending on the configuration of the automated system 110, the parser can cause the automated system to prepare intravenous doses, oral doses, or doses suitable for specific therapies such as chemotherapy. Typically, the automated system 110 is configured to prepare only one of these dosages types and so any dosage form outside the system's configuration (e.g., tablets) is rejected as not being suitable for handling. Those drug orders that are not suitable are sent to the label printer 130 as a serial data output stream 190. Consequently, the listener/parser module 100 enables drug orders to be better managed, with those susceptible to automated preparation being prepared without user intervention and with only those drug orders that are not suitable for the automated system 110 being sent to the label printer. This arrangement thereby reduces the number of drug orders that require manual handling, determines which orders require manual handling, and provides a filtered output stream 190 at the label printer 130 consisting of only those jobs that require manual handling.
  • The operation of the listener software module and the parser software module are described with reference to FIGS. 2 and 3, respectively.
  • The listener software module opens a serial communications channel on a serial port of the automated system 110 at step 210. For example, the listener module can be communicatively connected with the port making the connection 170 to the OES 120. Once communications have been opened, the listener software module (LSM) listens to that serial port for any data, at step 220. Preferably, drug orders are preceded by a character or character string that marks the beginning of a serial data stream. The LSM continuously tests to see whether a beginning-of-string character is detected at step 230, because such character or string denotes the start of label data. If a beginning character is not detected, then the LSM loops back to the listening step 220. On the other hand, if the start of a label is detected, then the serial data is written to a database together with (e.g., by appending) metadata.
  • As soon as the output stream is written to the database, the database assigns a unique transaction number, at step 240, to a newly opened log entry or record that will contain the incoming serial data. The LSM generates other data that is written to each log entry including the date and time of the transaction, the name assigned to the particular LSM that is writing the new database record, the serial data itself (sometimes referred to as “transaction text”), a marker to indicate whether the record requires parsing, a reference pointer that permits one database record to refer to another (e.g., for error checking purposes), and error condition information concerning errors that were observed on the communications line 170 during data transfer. This information is assigned to the transaction at step 240 as well. All of this information can be reviewed, if desired, using a viewer that displays each log entry together with any error messages that might have been generated or associated with a particular database record.
  • At step 250, the serial data itself is written to the record that was opened at step 240. The serial data continues to be written to that record until a label with an end-of-string character is detected or until a time-out event (e.g., end-of-message reached if no activity for X milliseconds) is detected, at step 260. Depending on the format of the data of received from the OES 120, there may or may not be an end of data stream character delimiting the end of a particular drug order. In the absence on the specific end-of-string delimiter, one drug order can be distinguished from the next either by detecting a beginning-of-string character or by permitting a prescribed time period to pass since the last data came in. Until an end-of-string condition is determined, the serial data continues to be sent to the database at step 250 and the end-of-string test at step 260 is repeated. When the end-of-string condition is determined, the record is time stamped at step 270 and the process flow loops back to step 230 to determine if a beginning-of-string character has been detected. As a result of the foregoing steps, records are created in the database by the LSM.
  • With reference now to FIG. 3, the operation of the parser software module (PSM) is described. At step 305, the PSM queries the database for any data that is to be parsed (i.e., data records that are marked as requiring parsing). As noted above, the LSM engrafts metadata to the serial stream coming into the automated system 110 over the connection 170. Part of the metadata includes a marker that tracks whether a given record has been parsed already (Parse=“True”) or not (Parse=“False”). The marker can also be set to ensure that an error log entry is not parsed (by setting Parse to be “True” for that entry). The database query except 305 can take on a variety of forms, but generally selects all fields from the transaction log in which Parse=“False.” An index can be used to speed query processing, as understood by those of skill in the art. Essentially, the PSM uses the marker to determine which records have not been parsed, and returns a list of the labels that still must be parsed in order to fill all the drug orders (whether new or batch).
  • Using the returned list, a record is retrieved at step 310 and parsed by the PSM at step 315. Parsing is conducted in accordance with configuration rules that have previously been established for that LSM. The configuration rules can accommodate a variety of data formats including fixed formats, name-value pairs, and XML formats. For example, if the serial data is in a fixed format, then the drug order data will have prescribed positions within the serial data stream such as a patient name occupying character positions 15-45 on the fourth line of the label or positions 15-45 on the same line of the label as the word “patient.” As another example, if the serial data is in the name—value pair format, the data may be located between a variable delimiter (“<Patient>”) and an end-of-line character (e.g., CR, LF or both). Also, because the particular LSM is preferably identified in the data record, multiple data formats can be accommodated by the PSM and properly parsed by selecting a suitable set of configuration rules. A set of configuration rules, therefore, enables proper parsing of the data from the printer output stream into the data structure used by the PSM to determine suitability for handling and handling of drug orders by the automated medication preparation system.
  • With brief reference to FIG. 4, a distributed system 400 is illustrated in which the automated system 410 comprises the PARxD IV drug preparation system of For Health Technologies, Inc. The system 410 has a parser software module 415 executing as a resident software application on one machine. In this arrangement, there are two order entry systems, denoted 420A and 42013, comprising physically different machines than the one executing the PSM 415. The OESes 420A, 420B also comprise physically distinct systems, such as an in-patient system and an outpatient system configured to service different patient sets. Each OES has its own LSM 425A, 425B, respectively, which writes data records having uniquely assigned transaction numbers to a database 435. OES 425A and 425B can have different data formats, yet because each new data record identifies the source of the record (L1 or L2), the parser 415 can properly parse records as they are retrieved at step 315.
  • Continuing the discussion of FIG. 3, a test is made at step 320 to determine whether the data received from the OES was received correctly. For example, the test can ensure that the checksum was valid and check its type (Mod 43, 16-bit cycle redundancy check (“CRC”), 32 bit CRC, etc.). If the data entered into the data record did not write correctly, the error is written to the database at step 325, for example as a new log entry, and the next database record in the list is retrieved at step 360. The new log entry preferably includes a reference pointer back to the log entry that had the error.
  • On the other hand, if the checksum were valid, then the transaction data is populated into a data structure at step 330. The data structure is selected to be compatible with the automated system 110, 410 and serves to assign each of the required data values with a variable. The variables that are included in the data structure can include, but are not limited to: the patient's name, location within the hospital or other institution, a drug code (e.g., the national drug code (“NDC”), the drug named in the drug order, the dose, the units, the administration date, the administration time, the order date, the order time, the checksum, any label comments, the order type (e.g. batch or new), and order frequency (e.g. “q6h6,” for every six hours starting at 6 A.M.).
  • With the serial data now contained in the data structure of the automated system 110, 410, the drug order is tested at step 335 by the parser to see whether it is suitable for handling by the automated system. A given drug order is generally suitable for handling unless one of the following limited circumstances exists:
      • 1. The automated medication preparation system cannot recognize the drug code included in the drug order.
      • 2. The automated medication preparation system recognizes the drug code but does not handle the drug in the drug order and therefore cannot fill the drug order.
      • 3. The automated medication preparation system understands the drug code and ordinarily can fill the drug order, but does not have the required drug in stock at the present time.
      • 4. The parser encounters an error while parsing of the data.
  • Apart from these three circumstances, the test at step 335 should result in a determination that the drug order can be handled by the automated system. Preferably, the test for suitability for handling is made with reference to an order database that maintains tables of data concerning drug names and drug codes associated with those names in various dosages. In the event of the drug cannot be handled by the automated system, the next step 340 the drug order is forwarded to the label printer 130 for printing (e.g., onto an adhesive label) and manual handling by staff. If, however, the test that step 335 resulted in the determination that the drug order can be handled by the automated system, then the populated data structure is forwarded to the automated system for handling at step 345. In sophisticated applications, the data structure can first be routed to a scheduler for queue handling in accordance with a prescribed priority. For example, a new order can be processed ahead of a batch order if the prescribed priority is “whether time permits” such routing. It should be understood that the step of determining whether the drug order is suitable for handling results in the drug order being automatically processed or, if not automatically processed, a label being generated for only those drug orders that cannot be automatically processed. This results in proactive and dynamic filtering of drug orders as they come in over serial data lines from order entry systems, in view of the capabilities of the automated systems and their current stock of medications.
  • At step 350, a test is made to determine whether there are any more listed records to retrieve in response to the database query at step 305. If there are no more records to retrieve, the process ends at step 355. Otherwise, if there are more records, the next record is retrieved at step 360 and the process flow loops back to step 315 where the newly retrieved record is parsed in accordance with the configuration rules for the listener that created that record.
  • In operation, the PSM may return several different errors, each of which is preferably recorded as a log entry in the database. In the process flow of FIG. 3, steps 315, 320, and 330 are marked with an asterisk (“*”) to indicate the steps at which errors might be returned. In particular, if data is missing that was expected to be included in the transaction data or that was to be provided by the LSM, an error code could result at step 315. If the checksum test at step 320 determines that the checksum is missing or does not match, an error code results and is written to the error log at step 325. Also, if required data is missing, the parser will determine this when populating the data structure with the transaction data, at step 330. Other errors can result which are not specifically noted above concerning interactions between the parser and one or more automated systems. A reference pointer to the problematic data record is preferably included whenever appropriate. A reference pointer is not appropriate, for example, when the error concerns a failure of the serial port or other hardware error.
  • It should be understood that the one-way serial listener interface lacks hand-shaking to permit confirmation that all information has been received intact from the OES. A more robust protocol such as HL7 over TCP/IP using a minimal lower layer protocol can be used, if necessary, to provide such confirmations.
  • The LSM is designed to trap a serial output stream of the type that is ordinarily sent to a label printer. This output stream is in the clear, that is, is non-proprietary, and includes critical information for preparing a medication. Thus, by trapping the output stream ordinarily intended for a label printer, the automated system can ensures compatibility with any hospital information system.
  • While the above discussion has focused on the capture and processing of serial data streams intended for printer devices in a hospital pharmacy, the present invention also can be used to monitor or listen to many varying types of network data transmissions between and among network components or to monitor data transmissions stored locally within a networked component regardless of whether the data is transmitted as serial data or to a serial port. As such, the invention can be adapted to capture, process, and automate the handling and preparation of medications using systems that are at least partially paperless or do not rely on printers for order management and fulfillment. Also, the invention can be adapted for use within an OES 120 that is not directed specifically to the printing of medication labels, but which more broadly is configured to manage the transmission and processing of medication orders, such as within or to a pharmacy. Data transmissions can be monitored between and among devices in communication over a network. Monitoring can be performed by the LSM between various network devices including similar devices (e.g., between computers) or between a dissimilar devices (e.g., computer and a networked printer). Thus, for example, data transmission can be monitored by a standalone network LSM positioned within a network to intercept or “sniff” (e.g., receive without affecting the data being transmitted) network communications. If a standalone component is used, it can be configured to relay suitable medication orders to a separate automated system 110. Alternatively, the LSM can include software executing on one of the networked devices (e.g., the automated system 110). For example, monitoring software can be programmed into the network protocol stack of a network device so as to intercept data transmissions when received, or after being received, by the device. Data transmissions can be intercepted covertly such that the application intended to receive the communication is unaware of the interception, or, alternatively, the data transmission interception can be known or publicized to other components in the system.
  • Alternatively, data transmissions can be monitored within a networked device in cooperation with another software application. For example, the LSM can include an email filter configured to monitor incoming email or monitor email contained in a specific set of folders. Monitored email messages can be parsed by the PSM to extract the data necessary to fulfill medication orders. In one particular configuration, an email program monitors email messages when or after they are received. The email message is parsed by the PSM and tested to determine if it is suitable for handling by the automated medication preparation system 110. If the data contained within the message cannot be handled by the automated medication preparation system 110, it is released to be handled by the email program in the ordinary manner in which such messages are handled (e.g., forwarded to a specific email address for manual processing).
  • In a further example of monitoring data transmissions between networked components, the LSM can include a software program configured to receive instant messages (e.g., AIM, Jabber, Yahoo Messenger, and ICQ) and/or monitor instant messages sent to a specific user for processing at a pharmacy. Monitoring can be performed in a manner similar to the monitoring of email as discussed above, with messages received by the IM software being parsed when or after they are received. Alternatively, an automated instant messaging software program (“bot”) can be configured to act as the destination of messages containing medication order information. The bot can act as the destination (e.g., the interface to the automated system 110), or alternatively can act as an intermediary that receives and distributes messages suitable for automated handling to the automated medication preparation system 110 and forwards messages that are not suitable for automated handling to a manual handling destination.
  • Data transmissions that are stored on a computer, for example files on a networked disk drive or File Transfer Protocol (“FTP”) server, can be actively monitored by a software process. The process can poll a specific directory for new messages that contain data concerning medication orders. If a new file is present, the file can be processed in the above described manner thereby causing those portions of orders suitable for automated handling to be fulfilled by an automated medication preparation system and relaying the portions of orders not suitable for automated handling to a specified destination for manual fulfillment.
  • An order that is not suitable for automated handling can be forwarded to a specified destination for manual order fulfillment. In a particular implementation, the portions of a data transmissions that are unsuitable for automated processing are forwarded to a printer. In an alternative implementation, those portions of orders can be relayed in their original format, or transformed into a new format. For example, medication orders contained in a file on a networked disk drive that are unsuitable for automated handling can be converted into an email and sent to the appropriate address for manual fulfillment within the pharmacy.
  • Monitoring and processing of data transmission can be performed in a distributed environment, such as an environment having multiple order entry systems 120 and multiple automated medication preparation systems 110 or manual medication preparation stations. Thus, LSMs can exist at a variety of locations throughout the system. A particular LSM can listen to all data transmissions it receives, or it can be associated with a particular source or destination. Thus, the LSM can process all information it receives or filter the received data transmissions for its associated source or destination. Similarly, multiple PSMs can coexist within the environment. Each PSM can be associated with a particular medication preparation station (e.g., I.V. station or syringe station), and receive data transmissions designated for that station from one or more LSMs. Alternatively, PSMs can receive data transmissions from one or more LSMs and determine the designated medication preparation station after parsing the information. Thus, the invention can capture data transmissions in a variety of formats from a variety of sources, and distribute the information contained within the data transmissions to multiple machines configured to perform different tasks.
  • Regardless of how the data transmission is monitored, each transmission can be associated with the particular source from which it was sent. Each source can identify itself during data transmission or include its identity in the transmission. Alternatively, the system monitoring the information can record the source of the message. For example, if the messages are transmitted using a TCP/IP packet, the IP address of the source can be logged and associated with the transmission.
  • Other methods of source identification can be used alone or in combination. For example, email messages and instant messages identify the sender of the transmission. Further source identification can be accomplished by signing the data transmissions. In a particular implementation, cryptographic keys can be associated with the machines sending messages. These keys can be used sign outgoing messages such that the sender can be authenticated without further human action to authenticate the message.
  • Preferably, the source of the data transmission identified is authenticated by the automated system 110 as a valid source. Valid source ID's can be stored in the database 435 and compared with the source of the transmission. Alternatively, data transmissions that are signed can be authenticated through the user of a secure key server (not shown). The further processing of the data transmission can be predicated on the successful authentication of the source as a valid source. Thus, if the source is identified as invalid, the transmission can be logged, for example in the database 435, and stored with the determined source for future analysis or processing.
  • Moreover, each data transmission can be logged whether the source is determined valid or invalid. The transmission can be logged in the database 435, flat file, or by any other standard method known in the art. Various metadata and derivative data determined from analyzing the data transmission can be also be logged and associated with the logged data transmission. For example, the determined data source, parsed data, or any errors encountered while authenticating the source or parsing the data can be logged. Entries in the log that include errors can be flagged for analysis manually or by secondary systems. The log, or portions of the log, can also be displayed to a user or printed for review. Additionally, the log can be filtered and searched to generate reports based on various criteria or to enable a user to find a specific set of entries.
  • While the invention has been described in detail with particular reference to certain embodiments thereof, the invention is capable of other and different embodiments, and its details are capable of modifications in various obvious respects. As would be readily apparent to those skilled in the art, variations and modifications can be affected while remaining within the spirit and scope of the invention. Accordingly, the foregoing disclosure, description, and Drawing Figures are for illustrative purposes only, and do not in any way limit the invention, which is defined only by the claims.

Claims (19)

1-28. (canceled)
29. A method for processing data of an order entry system, the data comprising medication data and specifying at least one dose order of medication suitable to be delivered to a patient, comprising:
parsing, using a central processing unit, the data for prescribed information in accordance with a set of configuration rules;
determining, using the central processing unit with reference to an order database, suitability of the medication data in the parsed data for automated handling by an automated medication preparation system;
dividing the parsed data, using the central processing unit, into two mutually exclusive data comprising a first medication data that has been determined as being suitable for automatic handling by the automated medication preparation system and a second medication data that has been determined as not being suitable for automatic handling;
initiating a launch, using the central processing unit, of one or more automated medication preparation processes based on the first medication data to manufacture one or more doses that are suitable for delivery and administration to the patient, wherein each manufactured dose corresponds to the one or more medication data from the first medication data that was determined suitable for automated handling; and
directing, using the central processing unit, the second medication data, which was determined not suitable for automatic handling, to a printer as a filtered output consisting of only those jobs that require manual handling.
30. The method of claim 29, further comprising:
monitoring the data of the order entry system comprising the medication data using the central processing unit.
31. The method of claim 30, wherein the monitoring step comprises monitoring incoming messages associated with the data of the order entry system as a transmission from the order entry system.
32. The method of claim 31, wherein the data has an identifiable source.
33. The method of claim 32, wherein the set of configuration rules are associated with the identifiable source.
34. The method of claim 29, wherein the second medication data directed to the printer specifies at least a drug and a dose.
35. The method of claim 34, wherein the second medication data specifies a patient name corresponding to the dose order in the medication data included in the second medication data.
36. The method of claim 29, further comprising:
determining whether the parsed data was received from the order entry system correctly;
writing an error to a database for parsed data that is in error; and
populating a data structure with a remainder of the parsed data, whereby parsed data not received correctly from the order entry system are not among the data in the populated data structure.
37. The method of claim 36, wherein the data structure is compatible with the automated medication preparation system.
38. The method of claim 37, wherein the data structure includes a plurality of data values assigned with a corresponding variable, wherein the plurality of data values comprise at least one of a patient name, a location, a drug code, a drug name, a dose, units, an administration date, an administration time, an order date, an order time, a checksum, label comments, an order type, and an order frequency.
39. The method of claim 38, wherein the plurality of data values comprise each of a patient name, a location, a drug code, a drug name, a dose, units, an administration date, an administration time, an order date, an order time, a checksum, label comments, an order type, and an order frequency.
40. The method of claim 36, wherein the first medication data and the second medication data include all of the data in the populated data structure.
41. The method of claim 36, wherein the step of determining whether parsed data was received correctly includes reviewing data parsed from the order entry system in accordance with configuration rules associated with the data,
42. The method of claim 29, wherein the one or more manufactured doses have a label applied to the dose in order to be suitable for delivery and administration to the patient.
43. The method of claim 29, wherein none of the first medication data is included in the second medication data sent to the printer as part of the directing step.
44. The method of claim 29, wherein the automated medication preparation system is configured to prepare one of intravenous doses, oral doses, or doses suitable for a specific therapy.
45. The method of claim 29, further comprising saving the second medication data as a record in a database.
46. The method of claim 29, wherein the data comprises medication data concerning a plurality of respective patients and specifies a corresponding plurality of dose orders of medication to be delivered to respective ones of the plurality of patients.
US14/577,855 2001-11-21 2014-12-19 Data transmission capture in support of medication preparation Abandoned US20150205932A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US14/577,855 US20150205932A1 (en) 2001-11-21 2014-12-19 Data transmission capture in support of medication preparation
US14/734,944 US20150278477A1 (en) 2001-11-21 2015-06-09 Data transmission capture in support of medication preparation

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US09/991,048 US7096212B2 (en) 2001-11-21 2001-11-21 Serial data capture and processing
US11/466,354 US9053218B2 (en) 2001-11-21 2006-08-22 Data transmission capture in support of medication preparation
US14/577,855 US20150205932A1 (en) 2001-11-21 2014-12-19 Data transmission capture in support of medication preparation

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US11/466,354 Continuation US9053218B2 (en) 2001-11-21 2006-08-22 Data transmission capture in support of medication preparation

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/734,944 Continuation US20150278477A1 (en) 2001-11-21 2015-06-09 Data transmission capture in support of medication preparation

Publications (1)

Publication Number Publication Date
US20150205932A1 true US20150205932A1 (en) 2015-07-23

Family

ID=25536803

Family Applications (4)

Application Number Title Priority Date Filing Date
US09/991,048 Expired - Fee Related US7096212B2 (en) 2001-11-21 2001-11-21 Serial data capture and processing
US11/466,354 Active 2029-04-09 US9053218B2 (en) 2001-11-21 2006-08-22 Data transmission capture in support of medication preparation
US14/577,855 Abandoned US20150205932A1 (en) 2001-11-21 2014-12-19 Data transmission capture in support of medication preparation
US14/734,944 Abandoned US20150278477A1 (en) 2001-11-21 2015-06-09 Data transmission capture in support of medication preparation

Family Applications Before (2)

Application Number Title Priority Date Filing Date
US09/991,048 Expired - Fee Related US7096212B2 (en) 2001-11-21 2001-11-21 Serial data capture and processing
US11/466,354 Active 2029-04-09 US9053218B2 (en) 2001-11-21 2006-08-22 Data transmission capture in support of medication preparation

Family Applications After (1)

Application Number Title Priority Date Filing Date
US14/734,944 Abandoned US20150278477A1 (en) 2001-11-21 2015-06-09 Data transmission capture in support of medication preparation

Country Status (5)

Country Link
US (4) US7096212B2 (en)
EP (1) EP1454267A1 (en)
AU (1) AU2002365552A1 (en)
CA (1) CA2467216A1 (en)
WO (1) WO2003046767A1 (en)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150278477A1 (en) * 2001-11-21 2015-10-01 Baxter Corporation Englewood Data transmission capture in support of medication preparation
CN106485050A (en) * 2016-09-13 2017-03-08 广州慧扬信息系统科技有限公司 A kind of learning-oriented doctor's advice input method
US10347374B2 (en) 2008-10-13 2019-07-09 Baxter Corporation Englewood Medication preparation system
US10646405B2 (en) 2012-10-26 2020-05-12 Baxter Corporation Englewood Work station for medical dose preparation system
US10818387B2 (en) 2014-12-05 2020-10-27 Baxter Corporation Englewood Dose preparation data analytics
US10971257B2 (en) 2012-10-26 2021-04-06 Baxter Corporation Englewood Image acquisition for medical dose preparation system
US11107574B2 (en) 2014-09-30 2021-08-31 Baxter Corporation Englewood Management of medication preparation with formulary management

Families Citing this family (76)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9741001B2 (en) 2000-05-18 2017-08-22 Carefusion 303, Inc. Predictive medication safety
US9427520B2 (en) 2005-02-11 2016-08-30 Carefusion 303, Inc. Management of pending medication orders
US7860583B2 (en) 2004-08-25 2010-12-28 Carefusion 303, Inc. System and method for dynamically adjusting patient therapy
US10062457B2 (en) 2012-07-26 2018-08-28 Carefusion 303, Inc. Predictive notifications for adverse patient events
AU6172301A (en) 2000-05-18 2001-11-26 Alaris Meidical Systems Inc Distributed remote asset and medication management drug delivery system
US11087873B2 (en) 2000-05-18 2021-08-10 Carefusion 303, Inc. Context-aware healthcare notification system
US10353856B2 (en) 2011-03-17 2019-07-16 Carefusion 303, Inc. Scalable communication system
US7753085B2 (en) 2002-12-03 2010-07-13 Forhealth Technologies, Inc. Automated drug preparation apparatus including automated drug reconstitution
US10688021B2 (en) 2002-12-03 2020-06-23 Baxter Corporation Englewood Automated drug preparation apparatus including automated drug reconstitution
US7880909B2 (en) * 2003-05-20 2011-02-01 Bukowski Mark A Extensible framework for parsing varying formats of print stream data
US20050154368A1 (en) * 2003-11-21 2005-07-14 Vasogen Ireland Limited Medical material handling systems
EP1830782B1 (en) * 2004-12-22 2013-06-05 Intelligent Hospital Systems Ltd. Automated pharmacy admixture system (APAS)
US7783383B2 (en) * 2004-12-22 2010-08-24 Intelligent Hospital Systems Ltd. Automated pharmacy admixture system (APAS)
US8374887B1 (en) 2005-02-11 2013-02-12 Emily H. Alexander System and method for remotely supervising and verifying pharmacy functions
US7931859B2 (en) * 2005-12-22 2011-04-26 Intelligent Hospital Systems Ltd. Ultraviolet sanitization in pharmacy environments
US7814731B2 (en) 2006-10-20 2010-10-19 Forhealth Technologies, Inc. Automated drug preparation apparatus including a bluetooth communications network
US20080169044A1 (en) 2006-10-20 2008-07-17 Forhealth Technologies, Inc. Automated drug preparation apparatus including syringe loading, preparation and filling
US7900658B2 (en) 2006-10-20 2011-03-08 Fht, Inc. Automated drug preparation apparatus including drug vial handling, venting, cannula positioning functionality
WO2008058280A2 (en) * 2006-11-09 2008-05-15 Intelligent Hospital Systems Ltd. Control of fluid transfer operations
US8140351B2 (en) * 2007-02-08 2012-03-20 Fht, Inc. Centralized sterile drug products distribution and automated management of sterile compounding stations
US20080195416A1 (en) * 2007-02-08 2008-08-14 Forhealth Technologies, Inc. Automated centralized preparation of medications in anticipation of use
US9305042B1 (en) * 2007-06-14 2016-04-05 West Corporation System, method, and computer-readable medium for removing credit card numbers from both fixed and variable length transaction records
US11128601B2 (en) * 2007-08-28 2021-09-21 Spencer Health Solutions, Llc Methods, systems, and computer program products for compiling information for use in a command script for a product dispensing system
US8271138B2 (en) * 2007-09-12 2012-09-18 Intelligent Hospital Systems Ltd. Gripper device
US7979288B2 (en) * 2007-10-12 2011-07-12 Southwest Research Institute Automated interpretation of medical prescription text
US8225824B2 (en) 2007-11-16 2012-07-24 Intelligent Hospital Systems, Ltd. Method and apparatus for automated fluid transfer operations
US8595609B2 (en) * 2008-05-16 2013-11-26 Parata Systems, Llc Methods, systems and computer program products for creating and modifying labels used by pharmaceutical dispensing systems
US8386070B2 (en) * 2009-03-18 2013-02-26 Intelligent Hospital Systems, Ltd Automated pharmacy admixture system
US9930297B2 (en) 2010-04-30 2018-03-27 Becton, Dickinson And Company System and method for acquiring images of medication preparations
US8799767B2 (en) 2010-05-28 2014-08-05 Welch Allyn, Inc. Transformation of medical status data into executable programs
US9033006B2 (en) 2010-09-17 2015-05-19 Nicholas J. Perazzo Oral syringe packaging system for hospital pharmacies
US8353869B2 (en) 2010-11-02 2013-01-15 Baxa Corporation Anti-tampering apparatus and method for drug delivery devices
US8743885B2 (en) 2011-05-03 2014-06-03 Cisco Technology, Inc. Mobile service routing in a network environment
US9077661B2 (en) * 2011-12-23 2015-07-07 Cisco Technology, Inc. System and method for policy selection and switching function in a network environment
US11182728B2 (en) 2013-01-30 2021-11-23 Carefusion 303, Inc. Medication workflow management
US10430554B2 (en) 2013-05-23 2019-10-01 Carefusion 303, Inc. Medication preparation queue
EP2973370A4 (en) 2013-03-13 2016-08-17 Carefusion 303 Inc Predictive medication safety
WO2014159280A1 (en) 2013-03-13 2014-10-02 Carefusion 303, Inc. Patient-specific medication management system
US9794379B2 (en) 2013-04-26 2017-10-17 Cisco Technology, Inc. High-efficiency service chaining with agentless service nodes
US9379931B2 (en) 2014-05-16 2016-06-28 Cisco Technology, Inc. System and method for transporting information to services in a network environment
US9479443B2 (en) 2014-05-16 2016-10-25 Cisco Technology, Inc. System and method for transporting information to services in a network environment
EP3826028A1 (en) 2014-06-30 2021-05-26 Baxter Corporation Englewood Managed medical information exchange
WO2016040323A1 (en) 2014-09-08 2016-03-17 Becton, Dickinson And Company System and method for preparing a pharmaceutical compound
US11575673B2 (en) 2014-09-30 2023-02-07 Baxter Corporation Englewood Central user management in a distributed healthcare information management system
AU2015335629B2 (en) * 2014-10-24 2021-01-28 Baxter Corporation Englewood Automated exchange of healthcare information for fulfillment of medication doses
US10417025B2 (en) 2014-11-18 2019-09-17 Cisco Technology, Inc. System and method to chain distributed applications in a network environment
US9660909B2 (en) 2014-12-11 2017-05-23 Cisco Technology, Inc. Network service header metadata for load balancing
USRE48131E1 (en) 2014-12-11 2020-07-28 Cisco Technology, Inc. Metadata augmentation in a service function chain
US9762402B2 (en) 2015-05-20 2017-09-12 Cisco Technology, Inc. System and method to facilitate the assignment of service functions for service chains in a network environment
US11044203B2 (en) 2016-01-19 2021-06-22 Cisco Technology, Inc. System and method for hosting mobile packet core and value-added services using a software defined network and service chains
US10187306B2 (en) 2016-03-24 2019-01-22 Cisco Technology, Inc. System and method for improved service chaining
US10931793B2 (en) 2016-04-26 2021-02-23 Cisco Technology, Inc. System and method for automated rendering of service chaining
US10419550B2 (en) 2016-07-06 2019-09-17 Cisco Technology, Inc. Automatic service function validation in a virtual network environment
US10320664B2 (en) 2016-07-21 2019-06-11 Cisco Technology, Inc. Cloud overlay for operations administration and management
US10218616B2 (en) 2016-07-21 2019-02-26 Cisco Technology, Inc. Link selection for communication with a service function cluster
US10225270B2 (en) 2016-08-02 2019-03-05 Cisco Technology, Inc. Steering of cloned traffic in a service function chain
US10218593B2 (en) 2016-08-23 2019-02-26 Cisco Technology, Inc. Identifying sources of packet drops in a service function chain environment
US10361969B2 (en) 2016-08-30 2019-07-23 Cisco Technology, Inc. System and method for managing chained services in a network environment
US10225187B2 (en) 2017-03-22 2019-03-05 Cisco Technology, Inc. System and method for providing a bit indexed service chain
US10884807B2 (en) 2017-04-12 2021-01-05 Cisco Technology, Inc. Serverless computing and task scheduling
US10178646B2 (en) 2017-04-12 2019-01-08 Cisco Technology, Inc. System and method to facilitate slice management in a network environment
US10257033B2 (en) 2017-04-12 2019-04-09 Cisco Technology, Inc. Virtualized network functions and service chaining in serverless computing infrastructure
US10333855B2 (en) 2017-04-19 2019-06-25 Cisco Technology, Inc. Latency reduction in service function paths
US10554689B2 (en) 2017-04-28 2020-02-04 Cisco Technology, Inc. Secure communication session resumption in a service function chain
US10735275B2 (en) 2017-06-16 2020-08-04 Cisco Technology, Inc. Releasing and retaining resources for use in a NFV environment
US10798187B2 (en) 2017-06-19 2020-10-06 Cisco Technology, Inc. Secure service chaining
US10397271B2 (en) 2017-07-11 2019-08-27 Cisco Technology, Inc. Distributed denial of service mitigation for web conferencing
US10673698B2 (en) 2017-07-21 2020-06-02 Cisco Technology, Inc. Service function chain optimization using live testing
US11063856B2 (en) 2017-08-24 2021-07-13 Cisco Technology, Inc. Virtual network function monitoring in a network function virtualization deployment
US10791065B2 (en) 2017-09-19 2020-09-29 Cisco Technology, Inc. Systems and methods for providing container attributes as part of OAM techniques
US11018981B2 (en) 2017-10-13 2021-05-25 Cisco Technology, Inc. System and method for replication container performance and policy validation using real time network traffic
US10541893B2 (en) 2017-10-25 2020-01-21 Cisco Technology, Inc. System and method for obtaining micro-service telemetry data
US10666612B2 (en) 2018-06-06 2020-05-26 Cisco Technology, Inc. Service chains for inter-cloud traffic
US11394627B1 (en) * 2019-07-31 2022-07-19 Express Scripts Strategie Development, Inc. Systems and methods for monitoring inter-application communications in complex computing ecosystems
US11048866B1 (en) * 2019-12-13 2021-06-29 Intuit Inc. Ad hoc contact data capture
WO2023170680A1 (en) 2022-03-08 2023-09-14 Equashield Medical Ltd Fluid transfer station in a robotic pharmaceutical preparation system

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010044731A1 (en) * 2000-05-18 2001-11-22 Coffman Damon J. Distributed remote asset and medication management drug delivery system
USRE37829E1 (en) * 1990-12-06 2002-09-03 Automed Technologies, Inc. Automated prescription vial filling system
US6564121B1 (en) * 1999-09-22 2003-05-13 Telepharmacy Solutions, Inc. Systems and methods for drug dispensing
US6842736B1 (en) * 1998-10-21 2005-01-11 David J. Brzozowski Drug auditing method and system
KR20050054379A (en) * 2003-12-04 2005-06-10 한국전자통신연구원 Care and treatment system of dementia disease using pda and method using it
US7672859B1 (en) * 2000-11-16 2010-03-02 Gsl Solutions, Inc. Prescription order position tracking system and method

Family Cites Families (47)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3878967A (en) * 1974-04-03 1975-04-22 Sherwood Medical Ind Inc Medicament dispenser
US4653010A (en) 1984-10-26 1987-03-24 Baxter Travenol Laboratories, Inc. Compounding system
CN86101893A (en) * 1985-02-28 1986-11-05 佳能株式会社 Data communications equipment
US4847765A (en) * 1986-12-22 1989-07-11 General Electric Company Hybrid interrupt handling for computer-controlled imaging system
US4847764C1 (en) * 1987-05-21 2001-09-11 Meditrol Inc System for dispensing drugs in health care instituions
US5169642A (en) * 1988-06-24 1992-12-08 Abbott Laboratories Sustained-release drug dosage units
US5208762A (en) * 1990-12-06 1993-05-04 Baxter International Inc. Automated prescription vial filling system
US5339421A (en) * 1991-03-22 1994-08-16 International Business Machines Corporation General data stream parser for encoding and decoding data and program interface for same
US5646049A (en) * 1992-03-27 1997-07-08 Abbott Laboratories Scheduling operation of an automated analytical system
US5337919A (en) * 1993-02-11 1994-08-16 Dispensing Technologies, Inc. Automatic dispensing system for prescriptions and the like
US5832447A (en) * 1994-05-24 1998-11-03 Envoy Corporation Automated system and method for providing real-time verification of health insurance eligibility
US6141412A (en) * 1994-06-01 2000-10-31 Davox Corporation Unscheduled event task processing system
WO1995034153A1 (en) * 1994-06-08 1995-12-14 Hughes Aircraft Company Apparatus and method for hybrid network access
US5915089A (en) 1995-01-13 1999-06-22 Wallace Computer Services, Inc. Supplemental data processing system for processing ply-matching data generated during multiple-part product printing
US5883370A (en) * 1995-06-08 1999-03-16 Psc Inc. Automated method for filling drug prescriptions
US5805454A (en) 1995-08-10 1998-09-08 Valerino, Sr.; Fred M. Parenteral products automation system (PPAS)
US6048086A (en) 1995-08-10 2000-04-11 Valerino, Sr.; Fred M. Parenteral products automatic system (PPAS) with an oral/solid interface
US5963641A (en) * 1995-09-12 1999-10-05 Markzware, Inc. Device and method for examining, verifying, correcting and approving electronic documents prior to printing, transmission or recording
US5713485A (en) * 1995-10-18 1998-02-03 Adds, Inc. Drug dispensing system
US5797515A (en) 1995-10-18 1998-08-25 Adds, Inc. Method for controlling a drug dispensing system
US5597995A (en) * 1995-11-08 1997-01-28 Automated Prescription Systems, Inc. Automated medical prescription fulfillment system having work stations for imaging, filling, and checking the dispensed drug product
US5812410A (en) * 1995-12-14 1998-09-22 Rx Excel, Inc. System for dispensing drugs
US5884273A (en) * 1996-05-16 1999-03-16 Carmen M Neal Micro-computer and printer for printing a prescription slip
US5907493A (en) * 1997-01-31 1999-05-25 Innovation Associates, Inc. Pharmaceutical dispensing system
US6226745B1 (en) * 1997-03-21 2001-05-01 Gio Wiederhold Information sharing system and method with requester dependent sharing and security rules
US6006946A (en) * 1997-12-05 1999-12-28 Automated Prescriptions System, Inc. Pill dispensing system
JP4243783B2 (en) * 1998-06-18 2009-03-25 株式会社湯山製作所 Dispensing instruction system
US6202923B1 (en) * 1999-08-23 2001-03-20 Innovation Associates, Inc. Automated pharmacy
US7403901B1 (en) * 2000-04-13 2008-07-22 Accenture Llp Error and load summary reporting in a health care solution environment
US20020188467A1 (en) * 2001-05-02 2002-12-12 Louis Eke Medical virtual resource network
US6597969B2 (en) * 2001-06-22 2003-07-22 Shlomo Greenwald Hospital drug distribution system
US20030033532A1 (en) * 2001-08-10 2003-02-13 Body Health Resources Corporation System and method for forming an on-line buyer's club
US7529685B2 (en) * 2001-08-28 2009-05-05 Md Datacor, Inc. System, method, and apparatus for storing, retrieving, and integrating clinical, diagnostic, genomic, and therapeutic data
US7096212B2 (en) * 2001-11-21 2006-08-22 Forhealth Technologies, Inc. Serial data capture and processing
US6847861B2 (en) * 2001-11-30 2005-01-25 Mckesson Automation, Inc. Carousel product for use in integrated restocking and dispensing system
US6985870B2 (en) * 2002-01-11 2006-01-10 Baxter International Inc. Medication delivery system
US7860724B2 (en) * 2002-10-30 2010-12-28 Automed Technologies, Inc. System and method for management of pharmacy workflow
US7753085B2 (en) * 2002-12-03 2010-07-13 Forhealth Technologies, Inc. Automated drug preparation apparatus including automated drug reconstitution
US8082173B2 (en) * 2003-05-22 2011-12-20 Cecil Kost Drug sample fulfillment architecture
EP1830782B1 (en) * 2004-12-22 2013-06-05 Intelligent Hospital Systems Ltd. Automated pharmacy admixture system (APAS)
US8140351B2 (en) * 2007-02-08 2012-03-20 Fht, Inc. Centralized sterile drug products distribution and automated management of sterile compounding stations
US8554579B2 (en) * 2008-10-13 2013-10-08 Fht, Inc. Management, reporting and benchmarking of medication preparation
CA2889352C (en) * 2012-10-26 2021-12-07 Baxter Corporation Englewood Improved work station for medical dose preparation system
US20150286799A1 (en) * 2014-04-04 2015-10-08 Baxter Corporation Englewood Management of medication dose orders
US11575673B2 (en) * 2014-09-30 2023-02-07 Baxter Corporation Englewood Central user management in a distributed healthcare information management system
US11107574B2 (en) * 2014-09-30 2021-08-31 Baxter Corporation Englewood Management of medication preparation with formulary management
WO2016205666A1 (en) * 2015-06-18 2016-12-22 Medsentry, Inc. Medication dispensing device and method

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
USRE37829E1 (en) * 1990-12-06 2002-09-03 Automed Technologies, Inc. Automated prescription vial filling system
US6842736B1 (en) * 1998-10-21 2005-01-11 David J. Brzozowski Drug auditing method and system
US6564121B1 (en) * 1999-09-22 2003-05-13 Telepharmacy Solutions, Inc. Systems and methods for drug dispensing
US20010044731A1 (en) * 2000-05-18 2001-11-22 Coffman Damon J. Distributed remote asset and medication management drug delivery system
US7672859B1 (en) * 2000-11-16 2010-03-02 Gsl Solutions, Inc. Prescription order position tracking system and method
KR20050054379A (en) * 2003-12-04 2005-06-10 한국전자통신연구원 Care and treatment system of dementia disease using pda and method using it

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150278477A1 (en) * 2001-11-21 2015-10-01 Baxter Corporation Englewood Data transmission capture in support of medication preparation
US10347374B2 (en) 2008-10-13 2019-07-09 Baxter Corporation Englewood Medication preparation system
US10646405B2 (en) 2012-10-26 2020-05-12 Baxter Corporation Englewood Work station for medical dose preparation system
US10971257B2 (en) 2012-10-26 2021-04-06 Baxter Corporation Englewood Image acquisition for medical dose preparation system
US11107574B2 (en) 2014-09-30 2021-08-31 Baxter Corporation Englewood Management of medication preparation with formulary management
US10818387B2 (en) 2014-12-05 2020-10-27 Baxter Corporation Englewood Dose preparation data analytics
CN106485050A (en) * 2016-09-13 2017-03-08 广州慧扬信息系统科技有限公司 A kind of learning-oriented doctor's advice input method

Also Published As

Publication number Publication date
US9053218B2 (en) 2015-06-09
AU2002365552A1 (en) 2003-06-10
WO2003046767A1 (en) 2003-06-05
US7096212B2 (en) 2006-08-22
US20030097368A1 (en) 2003-05-22
CA2467216A1 (en) 2003-06-05
US20150278477A1 (en) 2015-10-01
US20070043767A1 (en) 2007-02-22
EP1454267A1 (en) 2004-09-08

Similar Documents

Publication Publication Date Title
US9053218B2 (en) Data transmission capture in support of medication preparation
US20200394208A1 (en) System and Method for Providing Patient Record Synchronization In a Healthcare Setting
US7089247B2 (en) System and method for resolving a discrepancy in a clinical data management system
US6754707B2 (en) Secure computer support system
US8555273B1 (en) Network for updating electronic devices
US20050193043A1 (en) System and method for processing audit records
US20070153711A1 (en) System and Method for Transferring Data Between Applications
US20070124310A1 (en) Distributed Computing System to Enable the Secure Exchange of Information Between Remotely Located Healthcare Applications
US20030154110A1 (en) Method and apparatus for wireless access to a health care information system
US20070219991A1 (en) System and method for delivering targeted data to a subscriber base via a computer network
EP2533494A1 (en) System and method of bed data aggregation, normalization and communication to third parties
WO2007062510A1 (en) Method and apparatus for parallel sequencing of messages between disparate information systems
AU2002314929A1 (en) System and method for bridging a clinical remote data entry product to a bock-end clinical data management system
US20090157837A1 (en) Ndma socket transport protocol
CN109995643A (en) Business mail push method and device
CN104081421B (en) Method of pairing electronic apparatus and user account within on-line service
WO1998056024A1 (en) Translation of messages to and from secure swift format
US20060085221A1 (en) Universal charge routing system for medical billing
JP3526073B2 (en) E-mail distribution method and distribution system
KR101039419B1 (en) Method for Processing Plural Call Messages
Selmyer et al. Interfacing the clinical laboratory: A primer for LBS managers
EP1228434A1 (en) Method and system for electronic data capture
WO1999018502A1 (en) Method for data communication involving message files created by standard-compliant equipment
Khan et al. Change History

Legal Events

Date Code Title Description
AS Assignment

Owner name: FORHEALTH TECHNOLOGIES, INC., FLORIDA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:OSBORNE, JOEL A.;TRIBBLE, DENNIS;KHAN, ABDUL WAHID;AND OTHERS;SIGNING DATES FROM 20060926 TO 20061025;REEL/FRAME:035330/0678

Owner name: BAXA CORPORATION, COLORADO

Free format text: MERGER;ASSIGNOR:FHT, INC.;REEL/FRAME:035331/0591

Effective date: 20121214

Owner name: BAXA-FHT, INC., COLORADO

Free format text: MERGER;ASSIGNOR:FORHEALTH TECHNOLOGIES, INC.;REEL/FRAME:035331/0357

Effective date: 20090227

Owner name: FHT, INC., COLORADO

Free format text: CHANGE OF NAME;ASSIGNOR:BAXA-FHT, INC.;REEL/FRAME:035383/0176

Effective date: 20090414

Owner name: BAXTER CORPORATION ENGLEWOOD, COLORADO

Free format text: CHANGE OF NAME;ASSIGNOR:BAXA CORPORATION;REEL/FRAME:035383/0232

Effective date: 20130101

STPP Information on status: patent application and granting procedure in general

Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION

STPP Information on status: patent application and granting procedure in general

Free format text: NON FINAL ACTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER

STPP Information on status: patent application and granting procedure in general

Free format text: RESPONSE AFTER FINAL ACTION FORWARDED TO EXAMINER

STPP Information on status: patent application and granting procedure in general

Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION

STPP Information on status: patent application and granting procedure in general

Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER

STPP Information on status: patent application and granting procedure in general

Free format text: FINAL REJECTION MAILED

STCV Information on status: appeal procedure

Free format text: NOTICE OF APPEAL FILED

STCV Information on status: appeal procedure

Free format text: APPEAL BRIEF (OR SUPPLEMENTAL BRIEF) ENTERED AND FORWARDED TO EXAMINER

STCV Information on status: appeal procedure

Free format text: EXAMINER'S ANSWER TO APPEAL BRIEF MAILED

STCV Information on status: appeal procedure

Free format text: ON APPEAL -- AWAITING DECISION BY THE BOARD OF APPEALS

STCV Information on status: appeal procedure

Free format text: BOARD OF APPEALS DECISION RENDERED

STCB Information on status: application discontinuation

Free format text: ABANDONED -- AFTER EXAMINER'S ANSWER OR BOARD OF APPEALS DECISION