Automated exchange of healthcare information for fulfillment of medication doses

Abstract

To provide automated exchange of healthcare information.SOLUTION: The healthcare information may comprise one or more dose orders corresponding to dose medications to be administered to a patient. The healthcare information may be received (e.g., from an EMR system such as a hospital information system (HIS) or the like) in the form of a healthcare information data stream. The information may then be standardized in to a standardized intermediate form. For instance, data may be parsed from the data stream and used to populate a staging table. In turn, data from the staging table may be transformed into an input format specific to a given dose fulfillment client to which the dose order is provided for fulfillment of the dose. Additionally, exception processing. logistical processing, and management functionality may be applied to the dose orders.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] Cross - Reference to Related Applications

[0002] This application claims priority from the following U.S. Provisional Application Nos.: 62 / 068,301 (filed Oct. 24, 2014), entitled "AUTOMATED EXCHANGE OF HEALTHCARE INFORMATION FOR FULFILLMENT OF MEDICATION DOSES", the contents of which are hereby incorporated by reference as if fully set forth herein.

Background Art

[0003] Although electronic healthcare information systems have advanced, the processes related to information exchange may still depend on manual operations by human users. Independent systems can operate to manage electronic medical records (EMRs), but the exchange of information between independent systems can be complicated due to the absence of a standardized data format or data exchange protocol. Furthermore, when data can be exchanged between independent systems to a certain extent, using unique semantics in each independent system can potentially complicate the exchange of data between them.

[0004] For example, when processing a dose order, a doctor or the like may rely on a hard copy order form to request a medical order to be administered to a patient. And the hard copy of the order form may be provided to the pharmacy by the following means: for example, physical transportation, fax, relay by phone, relay by email, etc. And when receiving information related to the dose order at the pharmacy, a technician may need to manually enter information related to the requested dose order (for example, by transcribing information from a hard copy or electronic copy of the information). Accordingly, a new instance of the EMR related to the requested dose order may be generated at the pharmacy based on the transcribed dose order. And the dose order may be executed by the pharmacy (for example, including: calculation of the dose order, review, compounding, and delivery).

Summary of the Invention

Problems to be Solved by the Invention

[0005] Accordingly, in one or more instances during the dose order process, it may be necessary for a human user to manually process information related to the requested dose order. For example, a human user may need to relay information from a physical hard copy order form to a pharmacy system. Further, a human user may need to retrieve information from a first system and then transcribe the information to a second system. For example, a human user may need to enter received order information into a pharmacy information system (PIS). In this regard, although the EMR system related to the generation of dose orders and the execution by the pharmacy has advanced, the exchange of healthcare information may still involve human intervention.

[0006] Moreover, the potential for delays and errors may be further heightened by the need for human intervention. For example, there are reports such as: 60% of clinicians engaged in parenteral nutrition orders report 1 to 5 order errors per month. Significantly, in the 1- to 2-year span reviewed, fatal complications or death may have resulted from 4.8% of parenteral nutrition order errors. Furthermore, transcription can delay the execution of an order, as reports indicate that up to 10% of parenteral nutrition orders require verification because, according to the reports, the most common causes for the need for verification include illegible writing, lack of important components, or instability of macronutrient components. In this regard, human error can occur in the following forms: transcription errors, EMR order entry errors, errors that result in information asymmetry, errors that result in the illegibility of the order form, errors related to re-entry of an order in the pharmacy system, or other points within the data flow that require human intervention. Therefore, by improving the exchange of healthcare information between independent healthcare systems, the reliance on human intervention can be reduced, thereby reducing the error rate when improving patient outcomes.

Means for Solving the Problem

[0007] In view of the above, the present disclosure generally relates to improved exchange of healthcare information. Specifically, the present disclosure presents systems and methods that can at least partially assist in reducing: the reliance on manual human interaction in the exchange of healthcare information between independent healthcare systems. And it can reduce the reliance on human interaction to facilitate information exchange, and improve the speed and accuracy of healthcare information that can be exchanged between independent healthcare systems. And it can facilitate at least a partially automated approach to healthcare information exchange.

[0008] Accordingly, using the automated health information exchange described herein can improve outcomes for patients, which improvement assists in reducing errors associated with human interaction in the exchange of healthcare information. Further, the speed of information exchange can be improved more efficiently in pharmacy operations. For example, one context in which the automated healthcare information exchange can be utilized is the context of dose order execution. Specifically, it can facilitate the automation of the exchange of healthcare information from dose order entry to dose order execution, and assist in reducing (and potentially eliminating) the need for human intervention in connection with the exchange of healthcare information between: an EMR system that facilitates dose order entry, a pharmacy information system (PIS) for the management of pharmacy operations, and a dose execution client for use in the execution of the medical dose to be administered to a patient. In the description herein, a dose order may relate to a required medical dose in any number of contexts including, for example, an IV dose, a parenteral nutrition (PN) dose, a total parenteral nutrition (TPN) dose, and the like.

[0009] Specifically, the disclosure presented herein can facilitate the reception and processing of healthcare information data streams by a platform interface module. The platform interface module can identify and parse the syntax of the healthcare information data stream, and can identify individual dose orders from the healthcare information data stream. In this regard, the healthcare information data stream can include a lot of data including: for example, a plurality of dose orders, or other data related to EMR data, or hospital information system (HIS) data. When identifying a dose order from the healthcare information data stream, the platform interface module may be operable to parse the syntax of the dose order. As a result, dose order data fields can be identified, and dose order metadata related to the dose order can be placed in the fields. The dose order data fields may correspond to the characteristics of the dose order (e.g., ingredient list, product requirements, administrative characteristics, patient information, or other appropriate data types related to the dose order). And for each dose order, the corresponding dose order metadata may be parsed by the platform interface module. A staging table can be generated and stored in the platform interface module related to the dose order. The staging table can include: a standardized intermediate format for storing dose order metadata related to corresponding dose order data fields for a given dose order.

[0010] In this regard, the following points should be understood: namely, different and various EMR systems (e.g., one or more HISs, one or more physician order entry (POE) systems, etc.) can be used to generate and / or send dose orders to the pharmacy. And by receiving and processing the health information data stream for generating the staging table, it is possible to facilitate the generation of a standardized intermediate format for the dose order. The standardized intermediate format can be beneficial because the dose order can be routed to one of a plurality of different dose order execution clients for the purpose of using it when executing the medical dose related to the dose order. And there is no need to facilitate the specific correlation between different EMR system formats and a specific dose execution client input format. Rather, a standardized intermediate form (e.g., a staging table) can be used. As a result, a plurality of different EMR system formats can be standardized into the standardized intermediate form. And then, the standardized intermediate form can be converted into one of a plurality of different input formats related to the different formats of each dose execution client. In this regard, when adding different EMR systems, the data from the EMR systems can be standardized into the standardized intermediate format. As a result, the system can process the dose orders received from the new EMR system, and in doing so, there is no need to generate application functions specific to each dose execution client for the new EMR system. Further, when a new dose execution client is added to the system, it is possible to achieve the conversion of data in the standardized intermediate format, but there is no need to generate application functions for the new dose execution client specific to each EMR system. Therefore, a powerful and modular data exchange system can be realized, which enables the following: using any one of a plurality of EMR systems in combination with any one of a plurality of dose execution clients.

[0011] In at least some embodiments, the dose order records managed in the staging table can have some dose order management functions applied thereto. For example, functions related to viewing, changing, prioritizing, or otherwise organizing dose orders can be applied to the dose order information stored in the staging table. And pharmacy management can be improved in the following aspects: People related to the operation of the pharmacy can also execute pharmacy management functions collectively on the dose orders stored in the staging table. For example, such pharmacy management can be performed on the dose orders and then the dose orders can be provided to a plurality of dose execution clients. Further, dose order management can be performed in a local manner as viewed from one or more dose execution clients. And pharmacy resources can be efficiently managed in relation to dose orders having different priorities, urgencies, etc.

[0012] The dose order information from the staging table can be retrieved by and / or provided to a dose execution client, which may be for use when formulating doses related to the dose order. In this regard, the dose order information in the staging table can be converted from a standardized intermediate form of the staging table to an input format related to the dose execution client. For example, a unique input format for a given dose execution client may be provided. Thus, by specifying a particular dose execution client for use when formulating dose orders, the following can be made possible: converting data from the staging table into a unique input format for a given client using the corresponding unique input format related to the specified dose execution client.

[0013] Mapping and / or conversion processes may occur with respect to converting information from a staging table into doses in a client-specific format. For example, converting dose order information from a standardized intermediate format into a proprietary input format for a given dose execution client can include the following: mapping dose order data fields from the staging table into the corresponding respective dose execution client input fields. In addition to specific mappings, data conversion may be performed. For example, the proprietary input format for a dose execution client can identify the form for the expected data. Thus, the data can be converted from the form provided in the staging table. As a result, the data complies with the form of the proprietary input format.

[0014] Furthermore, the dose order metadata associated with each corresponding dose execution client input field can be checked to make the following determinations: whether valid input for the dose order was provided from the staging table. If the data may be invalid (e.g., due to a syntax error, mapping error, conversion error, or some other error), exception handling may be generated. That is, the exception handling can enable the user to resolve any errors identified during verification, mapping, or conversion. The user's resolution of the errors can be used to change processing rules (e.g., verification rules, mapping rules, or conversion rules) for subsequent dose orders, etc. The user input corresponding to the resolution of the errors can be incorporated into the conversion and / or verification of subsequent orders. Therefore, in relation to the conversion process, exception handling related to the mapping, conversion, and / or verification of dose order metadata from the staging table can be performed in the manner described herein. Further, logistic processing may be performed. As a result, changes, cancellations, or other modifications to the dose order received during the processing of the dose order can be facilitated. The waiver processing and / or logistic processing may be performed at the same location or different locations. Further, the waiver processing and / or logistic processing may occur in the platform interface module, the conversion module, and / or the dose execution client.

[0015] Furthermore, log operations may be generated through the exchange of healthcare data between the independent systems described herein. And auditing, troubleshooting, etc. can be facilitated during any or all steps related to the exchange between the systems described herein. The log information generated during the healthcare information exchange may be managed by each independent system or aggregated in a single repository related to some or all of the steps of the data exchange. And the maintenance of records for auditing purposes, etc. can be improved in relation to the exchange of healthcare information between the systems described herein.

[0016] As contemplated herein, multiple dose execution clients can be employed in connection with the healthcare information exchange facilitated by the disclosure presented herein. For example, a dose execution client can include: a pharmacy workflow management application for use in manually compounding dose orders, an automated syringe filling platform, a TPN management module, automated compounders (e.g., for use in executing PN and TPN orders), an automated dose dispensing cabinet, or other dose execution clients that can be used to effectuate a physical dose associated with a dose order. Accordingly, at least some dose execution clients can include: an automated dose compounding system for executing dose orders without the need for human intervention. And in at least some embodiments facilitated herein, the processing performed on a dose order may be fully automated. As a result, there is no human intervention between the entry of a dose order by a physician or the like and the execution of the dose order by an automated dose execution client.

[0017] A first aspect of the disclosure presented herein includes a method for automated conversion of healthcare information by a conversion module. The conversion is performed between a first form from an electronic medical record (EMR) system and a second form associated with a dose execution client. The execution client is for formulating a dose according to the dose order of the health information data. The method includes: retrieving, by the conversion module, dose order metadata regarding a dose order from a staging table corresponding to the dose order. In the staging table, the dose order metadata received from the healthcare information data stream is arranged in a first form from the EMR system. Further, the staging table includes: a plurality of dose order data fields, where each corresponding part of the dose order metadata is arranged in the field. The method further includes: converting the dose order metadata into a predefined second form corresponding to the dose execution client, and providing the dose order metadata in the second form to the dose execution client, where the providing is for executing a dose related to the dose order based on the dose order metadata.

[0018] A plurality of refined features and additional features are applicable to the first aspect. These refined features and additional features can be used individually or in combination. Accordingly, each of the following features described below is not essential but may be used with any other feature or in combination with the features of the first aspect.

[0019] For example, the method can further include: receiving the healthcare information data stream from the EMR system at a platform interface module. The healthcare information data stream can include: information related to a dose order (e.g., among other information and / or unrelated data related to different dose orders). The method can also include: identifying the dose order from the healthcare information data stream, and parsing the dose order metadata for the dose order from the healthcare information data stream. The dose order metadata can include: one or more dose characteristics related to the dose order. The method can further include: placing the dose order metadata for the dose order in the staging table at the platform interface module, where the staging table is stored in a staging table database.

[0020] The staging table can store the dose order metadata in a standardized intermediate format. For example, the method can further include: receiving a first dose order in a first EMR form, and receiving a second dose order in a second EMR form. The first dose order and the second dose order may correspond to: dose orders having the same components. The form of the components in the first EMR form may be different from that in the second EMR form (e.g., due to different EMR sources or using different EMR formats). And the form of the components related to the first dose order may be the same as the form of the components related to the second dose order in the respective staging tables corresponding to the first dose order and the second dose order. Further, other dose data may be standardized (e.g., patient data, dose administration data, etc.).

[0021] The method can also include: identifying the dose execution client from a plurality of dose execution clients for execution of the dose order, at least partially based on the dose order metadata. Thus, each of the plurality of dose execution clients has a respective predetermined second form. And the converting may be at least partially based on the respective predetermined second form of the identified dose execution client. The staging table may be independent of any plurality of dose execution clients.

[0022] The converting can include: mapping the plurality of dose order data fields of the staging table to respective corresponding fields among the plurality of dose execution client input fields.

[0023] In one application, the dose execution client input fields may be defined by a unique input format associated with the dose execution client. Further, the converting can include: verifying the dose order metadata of the plurality of dose order data fields with respect to the unique input format for the corresponding fields among the dose execution client input fields. The verifying can include: associating the dose order metadata of the plurality of dose order data fields with the treatment record of the dose execution client with respect to each respective corresponding field among the dose execution client input fields.

[0024] In one embodiment, the method can include the following: exception handling (e.g., in response to confirmation, mapping, or conversion of dose order data). In this regard, the method can include the following: generating an exception in response to an error related to at least one of the mapping or the confirmation. Further, the exception can include the following: prompting a human user to resolve the error. Thus, the method can include the following: receiving input related to the resolution of the error from the human user. And the input can include at least one of the following: the correct mapping between the dose order data field of the staging table and the corresponding respective field of the dose execution client input field, or the correct correlation between a part of the dose order metadata and the treatment record of the dose execution client. Thus, the exception handling can further include the following: updating at least one of the mapping logic or the correlation logic for use in the mapping and the association, respectively, based on the input received from the human user.

[0025] In one embodiment, the method can include the following: updating the staging table to indicate that the dose order metadata for the dose order has been retrieved by the dose execution client. Accordingly, the processing status of the dose can be managed in the staging table to indicate the following: processed dose orders and unprocessed dose orders. The method can also include the following: managing the dose order (e.g., by organizing, prioritizing, etc.), and then providing the dose order metadata in the second form to the dose execution client. For example, managing can include the following: providing a user interface to enable the user to perform management functions on the dose order. Specifically, managing can include at least one of the following: changing the dose order metadata, canceling the dose order, organizing the dose order relative to other dose orders, or prioritizing the dose order relative to other dose orders.

[0026] Furthermore, the method can include: performing logistic processing on a dose order. The logistic processing can include: performing an operation on the dose order in response to receiving an EMR system message after receiving the dose order. The EMR system message can include at least one of: a dose order change message or a dose order cancellation message. Accordingly, the logistic processing can include determining whether dose order metadata has been provided to the dose execution client. And the logistic processing is at least partially based on the determination. The logistic processing can include: performing an operation on a dose order record, where the dose order record corresponds to an EMR system message and the message relates to a dose order record not provided to the dose execution client. For example, the logistic processing can include: providing data to the dose execution client, where the client is related to an EMR system message and the message relates to a dose order record provided to the dose execution client. Also, the data provided to the dose execution client related to the EMR system message may be converted into a form corresponding to the dose execution client.

[0027] In one embodiment, the dose execution client can include at least one of the following: a pharmacy workflow management application for manual compounding of dose orders, an automated dose compounding device, an automated total parenteral nutrition (TPN) compounder, or a dose dispensing cabinet. Further, the EMR system can include the following: a hospital information system (HIS). Accordingly, the method can include the following: the exchange of messages from an independent healthcare system including the EMR system and the dose execution client. The data exchanged between the EMR system and the dose execution client may not be able to be made compliant without using a healthcare information exchange system. For example, the healthcare information data stream may be in the Health Level 7 (HL7) format.

[0028] The method can also include the following: performing a logging operation of actions taken on a dose order and generating a log regarding actions taken on the dose order. The logging operation can include the following: aggregating a plurality of logs generated for each different action taken on the dose order.

[0029] The second aspect includes the following: A method for automated healthcare information exchange between an electronic medical record (EMR) system and a dose execution client for executing dose orders. The method includes the following: Receiving a healthcare information data stream at a platform interface module. The healthcare information data stream includes information related to a dose order. The method also includes the following: Identifying the dose order from the healthcare information data stream, and parsing dose order metadata regarding the dose order from the healthcare information data stream. The dose order metadata includes one or more dose characteristics related to the dose order. The method further includes the following: Placing the dose order metadata for the dose order in a staging table. The staging table includes the following: A plurality of dose order data fields, where each corresponding portion of the dose order metadata is placed in the field. The method further includes the following: Converting the dose order metadata into a default format corresponding to a specific dose execution client and generating the converted dose order metadata. The method also includes the following: A specific dose execution client accessing the converted dose order metadata, where the dose execution client is operable to retrieve the converted dose order metadata from the staging table and execute the dose order based on the converted dose order metadata.

[0030] A plurality of refined features and additional features can be applied to the second aspect. These refined features and additional features can be used individually or in combination. Accordingly, each of the following features described below is not essential, but can be used with any other feature or in combination with the features of the second aspect. For example, any of the features described in relation to the first aspect may be applicable to the second aspect.

[0031] A third aspect includes the following: a healthcare information exchange system for the exchange of healthcare information between an electronic medical record (EMR) system and a dose execution client for the execution of dose orders. The system includes the following: a stream processing module, where the module is operably communicable with the EMR system and receives a healthcare information data stream from the EMR system. The system further includes the following: a staging table database, where the database is operably communicable with the stream processing module and is for storing a staging table, and dose order metadata is arranged in the table, and the metadata is included in the healthcare information data stream. The staging table includes the following: a plurality of dose order data fields, where each corresponding part of the dose order metadata is arranged in the fields. The system further includes the following: a conversion module, where the module is functionally arranged between the staging table database and the dose execution client. The conversion module may be capable of the following operations: identifying a dose execution client for use during the execution of a dose order, and converting the dose order metadata into a predefined format corresponding to the dose execution client. Specifically, the predefined format defines dose order data fields related to the dose execution client and the corresponding dose order metadata format.

[0032] A plurality of refined features and additional features are applicable to the third aspect. These refined features and additional features can be used individually or in combination. Therefore, each of the following features described below is not essential but can be used with any other feature or in combination with the features of the third aspect. For example, any of the features described in relation to the first aspect can be applied to the third aspect.

Brief Description of the Drawings

[0033]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

DETAILED DESCRIPTION OF THE INVENTION

[0034] Although the present invention is subject to various changes and different forms, these specific embodiments are shown in the drawings by way of illustration and will be described in detail herein. However, it should be understood that: that is, the present invention is not intended to be limited to the specific disclosed forms, but rather, the present invention covers all modifications, equivalents, and alternatives included within the scope of the present invention as defined by the claims.

[0035] FIG. 1 conceptually depicts an embodiment of a system (100) for automated healthcare information exchange. The system (100) can include: an EMR system (110) that operably communicates with a platform interface module (120). In this regard, the EMR system (110) can provide a healthcare information data stream (105) to the platform interface module (120). Although a single EMR system (110) is shown in FIG. 1, it should be understood that: a plurality of EMR systems (110) can operably communicate with the platform interface module (120). The EMR system (110) may correspond to different EMR systems (110) in a given facility, or may correspond to a plurality of EMR systems (110) from a plurality of facilities. In any case, the platform interface module (120) can operably communicate with a conversion module (130). And the conversion module (130) can operably communicate with a dose execution client (140). As will be described in detail later, the conversion module (130) can operably communicate with a plurality of dose execution clients (140). Thus, the conversion module (130) can include a dose routing module and / or can perform a dose routing function in relation to the dose order received by the conversion module (130).

[0036] In this regard, the system (100) in FIG. 1 may be operable to facilitate automated data exchange between independent healthcare information systems. For example, the EMR system (110) and the dose execution client (140) may each correspond to an independent healthcare information system and / or product. As described above, the EMR system (110) and the execution client (140) can use unrelated or incompatible data formats. Then, the platform interface module (120) and the conversion module (130) can act on the health information data stream (105) and convert the data from the form received from the EMR system (110). As a result, healthcare information (e.g., including dose order data) can be exchanged between the EMR system (110) and the dose execution client (140). Specifically, the data can be exchanged between the EMR system (110) and the dose execution client (140) in an automated manner, avoiding the need for human intervention with respect to the exchange of healthcare information. In this regard and as described above, the automation of the exchange of information between the EMR system (110) and the dose execution client (140) provided in accordance with the disclosure herein can help reduce errors and / or delays associated with human intervention with respect to the healthcare information data stream (105). Here, the stream is passed from the EMR system (110) to the dose execution client (140).

[0037] The EMR system (110) can include the following: a hospital information system (HIS). Thus, the healthcare information data stream (105) can include the following: information regarding a dosage order compounded by the dosage of the execution client (140). However, the healthcare information data stream (105) can also include the following: other healthcare information not related to the dosage order or the compounding of the dosage order. For example, in the case of HIS, the healthcare information data stream (105) can include the following: data related to patients (e.g., admission / discharge data), hospital management data (e.g., resource availability, scheduling, etc.), billing and accounting data, or other incidental data not related to the dosage order or the compounding of the dosage order.

[0038] The healthcare information data stream (105) may be provided in a plurality of different formats. Further, a given single platform interface module (120) can interface with a plurality of different ERM systems (110), and each ERM system can potentially provide the healthcare information data stream (105) in a different format. In one embodiment, the healthcare information data stream (105) can include the following: a Health Level 7 (HL7) format. The HL7 format means a set of loosely standardized agreements for the transfer of clinical and administration data between HISs. Although the agreements are loosely standardized by HL7 messages, the exchange of healthcare information between various independent healthcare systems using the HL7 format is not seamless. In this regard, different systems can use the following: different lexicons, agreements, semantics, or other different specifications within the HL7 format. As a result, the exchange of information between two systems using the HL7 format may still require an intermediary to enable data exchange between the systems.

[0039] Accordingly, the platform interface module (120) can receive the healthcare information data stream (105) from the EMR system (110), regardless of the nature of the format used (e.g., regardless of variations of the HL7 format). For example, different specific EMR systems (110) (e.g., different HISs) can use various HL7 formats, all of which can be received by the platform interface module (120). As will be described in more detail later, the platform interface module (120) is operable to identify and / or parse dosage orders from the healthcare information data stream (105). And the platform interface module (120) can store the record of the dosage orders identified and parsed from the healthcare information data stream (105) in a standardized intermediate format. For example, the standardized intermediate format can include: a staging table for each respective dosage order, where dosage order metadata regarding the dosage order is parsed from the healthcare information data stream (105). And the parsed dosage order metadata can be used to populate the fields of the staging table, which corresponds to the dosage order data fields from the healthcare information data stream (105).

[0040] The following points should be noted: namely, the standardized intermediate format (i.e., the staging table) may be standardized for different HL7 formats used by different HL7 providers. That is, if a first HL7 provider provides a dose order having the same components as a second HL7 provider, a part of the HL7 message corresponding to the same component regarding that dose may still differ based on: the difference in the HL7 formats used by the first and second providers to describe the same component. However, the platform interface module (120) can standardize different parts of the HL7 message regarding the components of the same order. As a result, the components regarding that order will have the same representation in the standardized intermediate format. Further, patient data, dose administration data, or other data related to the dose can be provided in different formats, which correspond to different uses of the HL7 format. However, such data may also be standardized in the standardized intermediate format. In this regard, the staging table including the standardized intermediate format can standardize the HL7 messages received in different healthcare data streams (105).

[0041] The generation of a standardized intermediate format is shown in Figure 18. In this figure, a user interface 1800 is depicted, which can display a list 1805 of received dose orders. The user can select a dose order 1810, which is one selected from the list 1805 of dose orders. When the selected dose order 1810 is selected, the corresponding information regarding the selected dose order 1810 can be displayed as follows: an error pane 1820, a pre-standardization pane 1830, and a post-standardization pane 1840. In this regard, the error pane 1820 can provide information regarding errors to the user (e.g., syntax errors, identification errors, or other errors that may occur in relation to receiving a dose order from the EMR system (110)). Further, the pre-standardization pane 1830 can display the dose order record in the state when it is received from the EMR system (110). In this regard, the pre-standardization pane 1830 can display the text representation of the HL7 message received from the EMR system (110) before performing standardization regarding placement into the staging table. The post-standardization pane 1840 can display the corresponding text representation of the dose order after it is standardized into the standardized intermediate format. That is, the post-standardization pane 1840 can provide a standardized version of the pre-standardization HL7 format displayed in the pre-standardization pane 1830. Therefore, the user interface 1800 enables the user to review errors related to the selected dose order 1810. Further, the user can review the pre-standardized format and the post-standardized format side by side for a given dose order, facilitating review and / or troubleshooting related to the dose order.

[0042] Using a standardized intermediate format can be particularly beneficial for multiple healthcare data stream providers (e.g., multiple EMR systems (110) that can include, for example, HIS, PIS, POE, or other healthcare information data stream (105) sources) and multiple dose execution clients (140). For example, for all possible combinations of EMR systems (110) and all dose execution clients (140), it is not necessary to develop specific conversion logic, and the system (100) can provide a more modular approach. That is, when a new EMR system (110) is added to the system (100), a parsing module (described in more detail later) can be provided to format the healthcare information data stream (105) into a standardized intermediate format for storage in a staging table. And all existing dose execution clients (140) can receive the information because the conversion module (130) can convert the standardized intermediate format into the specific format of each dose execution client (140). Further, if different dose execution clients (140) are added to the system and the system requires its own input format, there is no need to develop conversion logic for each potential EMR system (110), and conversion logic for the standardized intermediate format can be generated. Thus, when additional components for exchanging data are added to the system (100), the standardized intermediate format enables the development of improved modules.

[0043] The conversion module (130) can access data regarding the dose order from the staging table managed by the platform interface module (120). The conversion module (130) can convert the accessed data within the standardized intermediate format of the dose order from the standardized intermediate format of the staging table into a specific format related to the dose execution client. In this regard, the specific format on the client side may correspond to the following: the unique input format related to and / or required by the dose execution client (140). In this regard, the unique input format for a given dose execution client (140) may have input fields, and the fields may correspond to the following: the dose order data fields of the staging table. In this regard, the conversion module (130) can map the dose order data fields to the corresponding input fields, and the input fields may be related to the unique input format for a given dose execution client (140). Further, the conversion client (130) can convert the dose order metadata from the first format stored in the staging table to a target format related to the unique input format for a given dose execution client (140). In this regard, the conversion module (130) can apply the conversion specific to the dose execution client (140) to the dose order data stored in the staging table, and the application is based on the dose execution client (140), and the client is specified for utilization to execute the corresponding dose order.

[0044] Accordingly, data regarding the dose order may be provided to the dose execution client (140), and may be provided in a format related to a unique input format associated with the dose execution client (140). As a result, the dose order data can be automatically provided to the dose execution client (140) (for the purpose of these dose execution clients (140) using it when executing the doses corresponding to the dose order data). As will be understood from the further details described below, the dose execution client (140) can include the following: any one or more of a plurality of different types of dose execution clients, where the clients can be used when executing doses related to the dose order. For example, the dose execution client (140) can include any one or more of the following: a pharmacy workflow management application for managing the manual compounding of doses, a total parenteral nutrition (TPN) client connected to and / or for processing in the compounding (e.g., automated compounding) of TPN dose orders, an automated syringe filler, a dose dispensing cabinet having pre-stored doses, etc. These can be assigned to execute the dose based on the received dose order data.

[0045] As can also be understood from the further details described below, the platform interface module (120) and the conversion module (130) can each include hardware and / or software. Further, the platform interface module (120) and the conversion client (130) may be provided collectively as a single module. That is, each module can include: hardware and / or software for performing the functions described below in relation to the platform interface module (120) and / or the conversion module (130) respectively. For example, each module can include, individually or collectively, one or more processors, which communicate operably with a memory device, which stores non-transitory machine-readable data that can be used to specifically configure the one or more processors to perform the functions related to the modules described below. In this regard, each module can also include a memory device, which stores a non-transitory machine-readable data structure (e.g., a hard drive, flash drive, memory module, or other suitable physical electronic memory), which is for storing non-transitory machine-readable data used for the specific configuration of the one or more processors.

[0046] Referring further to FIG. 2, an embodiment of a method (200) for automated healthcare information exchange between an EMR system (110) and a dose execution client (140) is shown as a flowchart. The method (200) is described herein in connection with the system (100) of FIG. 1, but it should be further understood that: the method (200) can be executed in connection with any other embodiment described hereinafter. Further, the method (200) is depicted in the form of a continuous flowchart with specific individual operations in a specific order, but it is intended that the steps of the method described hereinafter can be executed in any order (or simultaneously) unless otherwise specified. Also, in further embodiments of the method, it is intended that some steps may be omitted. That is, not all steps of the process need to be executed in each embodiment.

[0047] The method (200) can include: receiving (210) a dose order data stream (105) (e.g., a health information data stream (105) that internally includes one or more dose orders). As can be understood, the receiving (210) can include: the transmission of a dose order data stream from an EMR system (110). In this regard, the dose order data stream may be transmitted (i.e., pushed) from the EMR system (110) at the start, and / or may be transmitted (i.e., pulled) from the EMR system (110) upon request from the platform interface module (120). The method (200) can also include: identifying / parsing dose order metadata from the dose order data stream (215). In this regard, the identifying / parsing (215) can include: analyzing the dose order data stream (105) to identify individual dose orders from the data stream (105). For example, and as described above, the data stream (105) can include: a plurality of dose orders and / or data that has nothing to do with dose orders at all. And the identifying can include: delineating individual dose orders from the data stream (105). Accordingly, the identifying can include: recognizing data in a specific format indicating a dose order. Further or alternatively, the data stream (105) can include: express delineators that assist in identifying the individual data of the dose orders within the data stream (105). Further, the dose order metadata may be parsed from the data stream (105) from the perspective of individual dose orders. In this regard, the parsing can include: arranging one or more specific dose order data fields and the corresponding dose order metadata related to the data fields.These dose order data fields and the dose order metadata associated with the fields can be used when placing the dose order data fields. Further, standardization of the dose order metadata may be performed. As a result, the staging table containing the dose order data fields can include: standardized dose order metadata (i.e., in a standardized intermediate format).

[0048] Any one or more of any one or more of the dose order data fields may be included within the data stream (105) and may be provided and / or generated in a corresponding staging table associated with the identified / parsed dose order. As an example, a predefined staging table can be provided that includes: predefined data fields related to: patient-specific data, components of the dose order, details of dose order management, or other appropriate data fields related to: the dose order, management of the dose order, or the patient receiving the dose order. That is, any data fields related to the formulation and / or management of the dose order may be included in the data stream (105). And the data provided in relation to such data fields may be standardized to corresponding data fields in the staging table, where the table can include: predefined data fields in which the dose order within the data stream (105) is standardized. Further still or alternatively, a staging table having data fields corresponding to the fields of the dose order in the data stream (105) can be generated when receiving data corresponding to the dose order.

[0049] In connection with this latter aspect, the method can include: placing the identified / parsed dose order data from the data stream (105) into a staging table (220). For example, the staging table can include: data fields stored as a specific data structure corresponding to a standardized intermediate format. For example, the standardized intermediate format can be defined by a database schema related to the dose order. In this regard, dose order metadata for a given dose order data field can be parsed to the extent possible in relation to one of the given dose orders in the data stream (105) to generate a corresponding staging table instance (e.g., a row of the table and / or an entry or record of a unique staging table), and the identified / parsed (215) corresponding dose order metadata from the data stream (105) can be placed into the appropriate respective data fields according to the standardized intermediate format (220). And a staging table can be generated corresponding to each identified individual dose order, and the parsed dose order data can be placed into the table (220). It should be understood that: namely, individual staging tables for corresponding individual dose orders can be stored collectively in the database. In this regard, individual database files need not be generated for each individual dose order; rather, a specific staging table or a part of a larger staging table (e.g., a unique row or record) can be specifically related to a given dose order for the purpose of a specific identification for the given dose order.

[0050] The method (200) can include, as an option in at least some embodiments, determining (225) a dose execution client for use in formulating a given dose order. For example, dose order data included in a data stream (105) regarding a given dose order or multiple doses can include: explicit identification information of a dose execution client (140) for use in executing the corresponding dose order(s) (e.g., the healthcare information data system (105) can include: information indicating a dose execution client (140) for a given dose order derived as data provided by the EMR system (110)). That is, the EMR system (110) can transmit data indicating the desired dose execution client (140) and use this data to implement a specific dose order (e.g., by indicating the type of dose execution client or by indicating a specific identifier of the dose execution client), where the dose order is included in the healthcare data stream (105). In another example, the source of the data stream (105) can be identified, and the identification information of the source of the data stream (105) can be used, at least in part, to determine the dose execution client (140) to which the dose order is provided for execution. For example, all dose orders received from a given specific source can be defined as dose orders corresponding to a specific dose execution client (140) and for use in executing these specific dose orders from the specific source. Further, the determination (225) of the dose execution client (140) regarding the dose order can be based on: a part or more of the dose order data. For example, the dose order data can define characteristics of the dose (e.g., ingredients, amounts of ingredients, types of ingredients, etc.). And it can be used to determine (225) a dose execution client (140) for use in executing the dose order.In this regard, logic can be established according to any of the above examples to facilitate the determination (225) of the dose execution client (140) for a given dose order. For example, the logic can be executed by the client router (128) (e.g., as shown below in Figure 3), and the router can be provided in the conversion module (130). In other intended embodiments, the client router (128) can be provided in a remote form from the conversion module (130) (e.g., at the platform interface module (120) and / or as a completely separate module).

[0051] Furthermore, the method (200) can include, as an option in at least some embodiments, performing (230) dose management functions for the dose order received and stored in the corresponding staging table. For example, the dose order stored in the corresponding staging table may be reviewed, changed, prioritized, grouped, organized, or otherwise managed. Note the following: namely, the dose management functions that can be performed (230) may occur before the dose order data is received by the dose execution client (140) and / or when the dose order data is received by the dose execution client (140). That is, the dose management functions may be performed by the platform interface module (120), the conversion module (130), and / or the dose execution client (140). For example, the dose management functions may be performed by the queue management and prioritization module (152) of the dose execution client (140), and the module may be located in the platform interface module (120) (e.g., as a stand-alone module and / or as a component of the client router (128) or the conversion module (130)), and / or may be arranged between the platform interface module (120) and the dose execution client (140).

[0052] The method (200) can further include: converting the dose order data from a standardized intermediate format (e.g., a staging table) to a specific format related to the dose execution client (140) (e.g., a unique input format for a given dose execution client (140)) (235). As will be described in more detail below, the conversion (235) can include: mapping the dose order data fields of the staging table to input fields for the unique input format of a given dose execution client (140). Further, the dose order metadata for a given dose order stored in the dose order data fields can be converted to a format related to the unique input format of a given dose execution client (140). In this regard, the conversion (235) may at least partially depend on: determining the dose execution client for a given dose order as described above (225).

[0053] The method (200) can further include: providing the converted dose order data to the dose execution client (140) (240). In this regard, the dose execution client may request the converted dose order data (e.g., pulling the data from the platform interface (120) and / or the conversion module (130)), and / or the dose execution client (140) may have the converted dose order metadata sent to the client (e.g., the data may be pushed from the platform interface (120) and / or the conversion module (130)).

[0054] In any case, the method (200) can include: verifying the converted dose order metadata (245), where the metadata is metadata for a unique input format for a dose execution client (140) that receives or is scheduled to receive dose order data. For example, verifying (245) can include determining whether the required dose execution client input fields are present in the converted dose order data. Further, verifying (245) can include analyzing a portion of the converted dose order data to determine whether a corresponding portion of valid data is available in the unique input format for the dose execution client (140). In this regard, if the verification (245) fails, an exception can be generated for the dose order. And the method (200) can include: exemption processing for resolving errors associated with the verification (245). Details of examples of exception handling will be described later.

[0055] The method (200) can also include, as an option in at least some embodiments, performing logistic processing (250) with respect to a dose order. For example, the dose order data stream (105) can include different types of order messages. For example, the type of dose order message can relate to a new dose order, a dose order change request, a dose order cancellation request, or other suitable dose order requests. That is, the type of at least some processed dose order messages can require a subsequent action to be taken with respect to a previously received dose order. Thus, when dose order data is processed and provided to the dose execution client (140), and a subsequent dose order message is received that requires an action to be taken with respect to the dose order data provided to the dose execution client (140), additional logistic processing may be performed (250). This can include analyzing a previous dose order to determine the state of the previous dose order (e.g., whether the dose order has not yet been sent to the dose execution client, whether the dose has been executed, etc.). Further, the logistic processing can also include performing an action on the previous dose order as required by a subsequently received dose order message (e.g., changing, canceling, etc.). Further, it should be understood that a dose order message may be applied to a dose order routed to a first dose execution client (140), however, at the time of execution of the dose order message, it may be recalled from the first dose execution client (140) and provided to a second dose execution client (140).

[0056] The method (200) can also include: updating the staging table (255) to reflect receipt of a dose order at the dose execution client (140). For example, updating (235) can include: changing a data field of the staging table related to the content indicating the state of the dose order, where the state indicates that the dose order record has been provided to and / or received by the dose execution client (140).

[0057] The method (200) can further include: executing the dose (260) at the dose execution client (140). Executing (260) can include: preparing the dose corresponding to the dose order at the dose execution client (140). The preparation may be a manual operation to prepare the dose order, an automated operation to execute the dose order, or a combination thereof. Further, executing (260) can include: making the dose available (e.g., pre-preparing) to fulfill the dose order (e.g., providing instructions to the dose dispensing cabinet to make the prepared dose available for execution of the dose order, etc.).

[0058] Refer further to FIG. 3. An embodiment of a system (30) for automated healthcare exchanges is conceptually depicted. The system (30) can include the following: an EMR system (110) (wherein the system provides a healthcare information data stream (105) in the form of an HL7 data feed to the HL7 data feed port (122) of a platform interface module (120)). And the HL7 data received at the HL7 data feed port (122) can be provided to an HL7 parsing module (124). In this regard, the HL7 parsing module (124) can perform dose order identification / syntax analysis from the HL7 data feed received at the HL7 data feed port (122). Thus, the HL7 parsing module (127) can include the following: a stream processing module. The HL7 parsing module (124) can also determine the following: whether the dose order identified from the data stream (105) should be processed by the exchange system (30). For example, the dose may be processed by the system described herein, or based on the identified dose order, it may be transferred by the parsing module (124) to a different dose handling system.

[0059] In any case and as described above, the staging table may be arranged for the purpose of the dose order identified / syntax analyzed from the data stream (105). The staging table may have a predefined data structure, which may be arranged together with the data identified / syntax analyzed from the data stream (105). And using the dose order data, dose order metadata from the data stream (105) may be arranged in the fields within the staging table, where the fields may correspond to the dose order data fields. And the staging table regarding the dose order may be stored in a staging table database (126).

[0060] The staging table database (126) may be operably communicable with a central server (300), which may be located remotely from the platform interface module (120). In this regard, in the staging table database (126), data regarding dose orders stored as a staging table may be provided to the central server (300). The central server (300) may receive dose order data from a plurality of platform interface modules (120) (e.g., from different healthcare facilities implementing the platform interface module (120)). The central server (300) may facilitate backup and / or data aggregation services in relation to the dose order data.

[0061] The staging table database (126) may be operably communicable with a conversion module (130). In this regard, the conversion module (130) may be operable to retrieve a staging table from the staging table database for the purpose of converting dose order data included within the staging table. Further, the conversion module (130) may include: a client router (128). And the client router (128) may be operable to provide the converted dose order data (e.g., in a unique input format for a given dose execution client (140)) to an appropriate dose execution client (140). Although shown as a common module, the client router (128) may be provided separately from the conversion module (130) (e.g., as a stand-alone module or as a module connected to the platform interface module (120)).

[0062] As briefly described above, various methods for determining an appropriate dose execution client (140) to which a dose order is to be sent may be employed by the client router (128). In this regard, the client router (128) may employ any one or more of the above-described approaches to determine an appropriate dose execution client (140) that can be the recipient of the converted dose order data. In this regard, a plurality of clients (140A), (140B), and (140C) shown in FIG. 3 may be provided in operable communication with the client router (128). And the client router (128) can provide the converted dose order data to an appropriate one of the execution clients (140A), (140B), and (140C). As a result, an appropriate dose execution client (140) can be utilized to execute the dose corresponding to the dose order.

[0063] As can be understood, the determination of an appropriate dose execution client (140) to which a dose order is to be provided may affect the conversion of the dose order by the conversion module (130). In this regard, the conversion module (130) can include the described client router (128) or may be described as communicating bidirectionally with the client router (128). As a result, the conversion module (130) and the client router (128) can act collectively on the data in the staging table and can determine a dose execution client (140) that formulates the dose order. As a result, identifying the determined dose execution client (140) may at least partially affect the conversion applied to the dose order data by the conversion module (130). For example, when an appropriate dose execution client (140) is identified by the client router (128), the dose order data can be converted from the staging table using a unique input format for the identified dose execution client (140).

[0064] In other embodiments, (for example, as depicted in FIG. 5, which will be described in detail later), the conversion module (130) of the embodiment of the system (30) may be provided in the platform interface module (120). Further, and as will be described in more detail later in connection with other embodiments, the client router (128) may be disposed in the platform interface module (120). In this regard, the execution clients (140A), (140B), and (140C) may each be operable to receive the converted dose order data for use in the execution of the dose corresponding to the dose order. That is, in at least some embodiments, all processing related to dose order data for exchange with the dose execution client (140) may occur in the platform interface module (120). However, in other embodiments, for example as will be described later, different functions with respect to the conversion module (130) and / or the client router (128) may be provided in a manner that is separate from and distributed away from the platform interface module (120).

[0065] The platform interface module (120) can also include the following: a web server (310) that provides remote access to the functions provided by the platform interface module (120). For example, the web server (310) can manage and / or execute one or more web pages (312), and the web pages can correspond to various modules and / or various functions provided by the platform interface module (120). And the web pages (312) can be connected to the following to facilitate functions: the platform interface module (120) and / or the module provided with the platform interface module. For example, various settings, parameters, or other management functions can be executed in relation to the platform interface module (120). Such functions can be facilitated by means of the web pages (312), and the web pages can be accessed by means of the web server (310).

[0066] Refer further to FIG. 4, which depicts another embodiment of a system (40) for automated healthcare information exchange. The system (40) may be particularly useful in the execution of total parenteral nutrition (TPN) dose orders received from an EMR system (110). The system of FIG. 4 may be configured to perform the following operations: Receive TPN dose orders from the EMR system (110) in multiple formats. For example, the platform interface module (120) can include: an HL7 data feed port (122), where HL7 format messages from the EMR system (110) can be routed and parsed (as described above in connection with FIG. 3). The platform interface module (120) can also include: a TPN print data feed (402), to which print feed data messages from the EMR system (110) are routed. In this regard, the platform interface module (120) can facilitate both the ability to process HL7 format messages received from the EMR system (110) as well as print feed messages. Examples of HL7 message formats that can be processed include, but are not limited to, HL7 messages derived from EMR systems provided by: Cerner Corporation, Epic Systems Corporation, Meditech, Omnicell, Inc. or others. Further, examples of supported print feed formats include, but are not limited to: Zebra programming language provided by Zebra Technologies, DataMax format provided by DataMax-O’Neil, Intermec format provided by Intermec, Inc., Portable Document Format (PDF) provided by Adobe Systems, plain text format, etc.

[0067] In this regard, the HL7 message may be provided from the HL7 data feed port (122) to the HL7 parsing module (124) (as described above in connection with FIG. 3). Further, the TPN print data feed (402) may provide the print feed message to the label processor (404) of the platform interface module (120). In any case, the HL7 parsing module (124) and / or the label processor (404) may provide individual dose order metadata in relation to the corresponding dose order data fields, and the provision may be for the purpose of storing in the staging table database (126) as a staging table.

[0068] In the example provided in FIG. 4, the platform interface module (126) may communicate directly with the TPN execution client (142). In this regard, the TPN execution client (142) may be a dose execution client (140) capable of executing a TPN dose order. For example, the TPN execution client (142) may include: a TPN management module (144). The TPN management module (144) can facilitate the calculation and management of dose orders. For example, the TPN management module (144) can include the ABACUS Calculation Software provided by Baxter Healthcare Corporation of Deerfield, IL. In any case, the TPN execution client (142) can provide further related processing of the TPN dose order in relation to the execution of the TPN dose order. (For example, calculations regarding the interaction of components, etc.). The TPN management module (144) may further communicate with the TPN compounder (158). The TPN compounder (158) may be operable to automatically formulate a dose corresponding to a TPN order. In this regard, in one embodiment, the dose execution client (140) can include: a TPN execution client (142) collectively including the TPN management module (144) and / or the TPN compounder (158). That is, the conversion module (130) can communicate directly with the TPN management module (144) or the TPN compounder (158). Accordingly, the unique input format utilized by the conversion module (130) may correspond to the TPN management module (144) or the TPN compounder (158).

[0069] In this regard, and as depicted in FIG. 4, the conversion module (130) may be provided to operably communicate with the staging table database (126) and the TPN client (142). In this regard, the conversion module (130) can access the staging table database (126) to retrieve dose order data in a standardized intermediate format of the staging table, and the data may be converted by the conversion module (130) into a unique input format for use by the TPN client (142). In this regard, the system (40) of FIG. 4 may not include a client router (128). For example, the platform interface module (120) may be utilized in an exclusive manner to only receive TPN dose orders from the EMR system (110). In this regard, the TPN client (142) may access the staging table database (126) to retrieve all the staging tables contained in the database, the purpose of which may be to be converted by the conversion module (130) into a unique input format related to the TPN management module (144). That is, the platform interface module (120) may be used in a dose context-specific application, where the dose order to be executed by a given dose execution client (140) (e.g., the TPN execution client (142)) is processed by the platform interface module (120) as only one type.

[0070] Figure 5 depicts another embodiment of a system (50) for the exchange of healthcare information. The system (50) can also receive HL7 format messages as well as print feed messages from the EMR system (110), which are processed by the HL7 data feed port (122) and the print feed port (402) respectively, (as described above in connection with FIG. 4). As described above, the data messages may be routed to an appropriate one of the HL7 parsing module (124) or the label processor (404), the purpose of which may be to generate a staging table to be stored in the staging table database (126) for the corresponding received dose order. FIG. 5 further includes a manual order entry website (312A) (e.g., provided in accessing the website (312) by the web server (310) of FIG. 3). In this regard, the user may directly access the platform interface module (120) using the manual order entry website (312A), and may directly generate a dose order in the platform interface module (120), and the order may be stored in the staging table in the staging table database (126).

[0071] In an embodiment of the system (50) depicted in FIG. 5, the platform interface module (120) may communicate operably with a pharmacy workflow management application (146). In this regard, the pharmacy workflow management application (146) may be the sole dose execution client (140), with which the platform interface module (120) may communicate operably. In this regard, as depicted in FIG. 5, a conversion module (130) may be provided with the platform interface module (120) for the purpose of converting dose order data stored in a staging table of the staging table database (126) into a proprietary input format relevant to the pharmacy workflow management application (146). Upon receiving the converted dose order data, the data may be stored in a dose order record database (148) of the pharmacy workflow management application (146). And the dose order may be provided to a pharmacy workflow management module (150). The pharmacy workflow management module (150) may enable manual compounding of the dose order by a pharmacy technician or the like. For example, embodiments of the pharmacy workflow management application (146) are described in the following numbered U.S. provisional applications having normal assignments: 62 / 057,906 (filed September 30, 2014) (inventive name "MANAGEMENT OF MEDICATION PREPARATIN WITH FORMULARY MANAGEMENT"), which is hereby incorporated by reference in its entirety. Such embodiments may be utilized to execute dose orders in the pharmacy workflow management application (146).

[0072] Refer further to FIG. 6. Another embodiment of a system (60) for automated healthcare information exchange is depicted. The system (60) can receive dosage order information from an EMR system (110) by means of: means of an HL7 data feed port (122), means of a printed data feed port (402), or means of manual order entry from a manual order entry website (312A) (as described above in connection with FIG. 5). In this regard, dosage order data can be received and used to place it in a corresponding staging table, which may be stored in a staging table database (126).

[0073] The system (60) of FIG. 6 further includes a plurality of dosage execution clients (140). For example, a platform interface module (120) operably communicates with a pharmacy workflow management application (146) and a TPN execution client (142). The system (60) of FIG. 6 can have a local conversion module (130A), which may be provided by the platform interface module (120). The local conversion module (130A) can perform data conversion on dosage order data, which may be provided to the pharmacy workflow management application (146). Further, a queue management and prioritization module (152) may be provided for the purpose of managing dosage orders, which may correspond to dosage order data to be provided to or provided to the pharmacy workflow management application (146).

[0074] Furthermore, the TPN execution client (142) may associate a remote conversion module (130B) with itself, where the module may be located remotely from the platform interface module (120), for the purpose of converting dose order data related locally to the TPN execution client (142) into dose order data corresponding to a dose order directed to the TPN execution client (142). In this regard, the system (60) of FIG. 6 may have different conversion modules (130A) and (130B), for the purpose of converting dose order data provided to the pharmacy workflow management application (146) and the TPN execution client (142), respectively. Further, a queue management and prioritization module (152) can be provided for at least some dose orders, which may be directed to a given one of the dose execution clients (e.g., the pharmacy workflow management application (146)). The queue management and prioritization module (152) may be operable to manage dose orders before or after data conversion related to the dose orders takes place. Thus, in FIG. 6, although shown as being between the conversion module (130) and the pharmacy workflow management application (146), one or more queue management and prioritization modules (152) may be provided elsewhere for the management of the dose order queue (e.g., in the staging table database (126), in the dose execution client (140), etc.).

[0075] As described above, briefly stated, the determination of the execution client (140) that can be the recipient of the dose order data can occur in multiple ways. For example, each client can access the staging table database (126) and request dose order data, which may be flagged (e.g., can include a data field indicating so) to be designated to a given dose execution client (140) that requests the information. Further, logic may be applied to the dose order data based on multiple different potential parameters, and the dose execution client (140) to be used during the execution of a given dose order may be identified. In this regard, the dose order data may be provided to the execution client (140) based on a data field for use during the execution of the dose order, and in the data field, the designated dose execution client (140) may be shown as determined by the application of the logic.

[0076] Further refer to FIG. 7. An embodiment of a system (70) for automated healthcare information exchange is depicted. The system (70) can receive dose order data from the EMR system (110) (as described above). The system (70) can also include: a conversion module (130D) that facilitates the conversion of data provided to one or more of the plurality of dose execution clients (140) (e.g., including the following in the depicted embodiment: the TPN client (142), the dispensing cabinet (154), or the automated syringe filler (156)). The conversion module (130D) can include: a client router (128).

[0077] In this regard, the dose execution client (140) of the system (70) can include: a pharmacy workflow management application (146), a TPN client (142), a dispensing cabinet (154) (e.g., an automated dose dispensing cabinet), and / or an automated syringe filler (156). A portion of the dose order from the staging table database (126) may be provided to the pharmacy workflow management application (146) by means of the conversion module (130). Another portion of the dose order may be provided to the conversion module (130D). And the client router (128) of the conversion module (130D) is operable to identify the dose execution client (140) to which the dose order is to be provided. Thus, the client router (128) can apply any suitable logic with respect to the dose order and can determine the appropriate dose execution client (140). For example, the client router (128) can identify and utilize a dose execution client flag in the dose order received from the EMR system and can direct the dose order to the appropriate dose execution client (140). Further, the client router (128) can dynamically route the dose order to the appropriate execution client (140), and this routing may be based on the dose order metadata included in the dose order. Specifically, the client router (128) may be operable to determine whether the dose order is suitable for automated compounding (e.g., by an automated syringe filler (156)). In this regard, if the dose order is suitable for automated compounding, the client router (128) can provide the dose order to the appropriate automated dose execution client (140) (e.g., an automated syringe filler (156), etc.). Further, the client router (128) may be operable to identify whether the dose order is suitable for execution by an automated dispensing cabinet (154).

[0078] As can be understood, with respect to processing specific dose order data, it may depend on a specific dose execution client (140) that is the recipient of the dose order. For example, when providing a dose order to one of the pharmacy workflow management applications (146), the conversion module (130C) is provided locally with respect to the platform module interface (120), but the conversion module can enable the conversion of dose order data in the staging table database (126) into a unique input format corresponding to the pharmacy workflow management application (146). Further, the conversion module (130D) may be provided (e.g., remotely from the platform interface module (120)), for the purpose of converting dose order data in relation to the TPN execution client (142), the dispensing cabinet (154), or the automated syringe filler (156). In this regard, the TPN execution client (142) can include: a TPN compounder (158), where the compounder is for the preparation of TPN dose orders, the preparation being in accordance with the dose order data, the data being received at the TPN client (142) and possibly converted by the conversion module (130D). Further, the TPN order management module (144) can provide information to the pharmacy workflow management application (146). Although shown as a direct connection, the following is expected: namely, the dose order data may be provided by means of the platform interface module (120) and / or the conversion module (130C). Furthermore, the dose order data may be provided to both the pharmacy workflow management application (146) and the TPN execution client (142), and what shows the correlation relationship between the dose order data may be provided to each respective dose execution client (140).

[0079] FIG. 8 further depicts a system (80) that, similar to the system (70) of FIG. 7, is operably communicable with the following: a pharmacy workflow management application (146), a TPN client (142), a dispensing cabinet (154), and / or an automated syringe filler (156). However, unlike the system (70) of FIG. 7, the system (80) of FIG. 8 can include: a single transformation module (130) provided in the platform interface module (120) for the purpose of transforming dose order data from a standardized intermediate format of a staging table stored in a staging table database (126) to a corresponding proprietary input format for a given dose execution client (140). In this regard, the platform interface module (120) can include: a client router (128) that is a router disposed between the staging table database (126) and an EMR system (110) or other order entry means. In this regard, the client router (128) may be operable to apply logic to determine: the appropriate one of the dose execution clients (140) to use with each of the dose orders. In this regard, the client router (128) may add information to the data in the staging table, the information being relevant to a given dose order indicating the dose execution client (140) to which the dose order is to be provided. Further, the client router (128) may be operably communicable with the transformation module (130) and can provide information regarding the dose execution client (140) to which a dose order is to be provided for a given staging table.

[0080] In any of the above embodiments, each system for automated transformed healthcare information can also facilitate a logging operation regarding the actions taken on a dosage order. The logging operation can include the following: generating a log reflecting the actions taken on the dosage order. The log may be managed for later review by a human user (e.g., in the performance of an audit, troubleshooting, etc.). The occurrence of the logging operation and the saving of the log may occur at different locations within the system. For example, the platform interface module (120) may perform the logging operation and generate a corresponding log. Further, the transformation module (130) (regardless of the specific location of the module within the system) may also perform the logging operation and generate a corresponding log. In this regard, the log may be managed at different locations within the system. Further still or alternatively, the log may be transmitted to a common location within the system. For example, the platform interface module (120) may be operably communicable with the transformation module (130), or the dosage execution client (140), and receive from them a log of the processing regarding the dosage order. In this regard, the logs of one or more locations of the system may be collectively stored at a given point within the system (e.g., the platform interface module (120), etc.).

[0081] Further, refer to FIG. 9. It represents the data transformation executed by the transformation module (130). Specifically, FIG. 9 includes a textual representation of the data transformation in a format recognizable by a human. FIG. 9 includes an illustration of an embodiment of a data feed (500). As can be understood, the data feed (500) can be analyzed (e.g., by the syntax analysis module of the platform interface module (120)). By the said syntax analysis, a dosage order (502) and a specified dosage order (504) can be generated. As can be understood, a part (518) of the data stream (500) may not correspond to a dosage order.

[0082] The dose order (502) can be parsed. As a result, a plurality of dose order data fields are recognized. Specifically, the dose order (502) can include: a first patient data field (506), a second patient data field (508), a first component field (510), a second component field (512), an administrative data field (514), and a patient procedure data field (516). Additional data fields may exist, or the data fields may be fewer. Thus, what is presented here is for illustrative purposes only. The second dose order (504) can be parsed. As a result, a first data patient field (524), a first component field (526), and an administrative data field (528) are identified. In this regard, the data regarding the first dose order (502) and the data regarding the second dose order (504) can be stored in a staging table respectively. Thus, the text representation of the first dose order (502) may correspond to the staging table for the first dose order (502), and the text representation of the second dose order (504) may correspond to the staging table for the second dose order (504). Although textually represented in FIG. 9, it should be understood that: namely, the actual staging table may be managed in a different format (e.g., XML format, SQL database format, or other suitable format).

[0083] In any case, the conversion module (130) may be operable to map data fields from the staging tables (502) and (504) to corresponding fields in a proprietary input format for one or more dose execution clients (140). For example, a first input (552) can be generated that corresponds to the staging table for the first order (502). As will be appreciated, the first input (552) may define fields according to a proprietary input format for a particular dose execution client (140). Accordingly, appropriate fields among the data fields in the staging table (502) may be mapped to the fields in the first input (552). Specifically, the first patient data field (506) and the second patient data field (508) may be mapped to the client patient information field (556) of the first input (552). In this regard, it should be understood that: that is, a plurality of data fields from the staging table (502) may be mapped to a single field in the first input (552). In this regard, data from multiple fields of the staging table (502) (e.g., the first patient data field (506) and the second patient data field (508)) may be aggregated or reformatted to be included within the client patient input (556). Further, a portion of the data included in one of the first patient data field (506) or the second patient data field (508) may be omitted.

[0084] Further, an example of the matching between the data fields in the staging tables (502)(504) and the first and second inputs (552)(554) is shown in FIG. 9. Specifically, the first component field (510) and the second component field (512) can be mapped to the dose component input (558) of the first input (552). Further, the management data field (514) of the first staging table (502) can be mapped to the management data input (560) of the first input (552). It should be noted that not all data fields of the first staging table (502) are mapped to the first input (522). For example, the patient procedure data field (516) may be irrelevant to the dose order, and thus, the first input (552) corresponding input field mapped to the patient procedure data field (516) may not be required. Further, in the first staging table (502), although it is shown that a plurality of data fields from the staging table (502) may be mapped to a single information field within the first input (552), the following point should also be understood: that is, a one-to-one correspondence can also be provided (for example, in the case of the second dose order (504)). In this regard, the first patient data field (524) of the second dose order (504) may be mapped to the client patient input (562) of the second input (554). Further, the first component field (526) may be mapped to the dose component input (564), and the management data field (528) may be mapped to the management data input (566). Further, the following point should be noted: that is, a part (518) of the data stream that does not correspond to the dose order may not be mapped to any client input. That is, at least one platform interface module (120) or conversion module (130) can recognize the part (518) that does not correspond to the dose order. As a result, the corresponding input is not generated, or the mapping corresponding to the part (518) is not performed.

[0085] In addition to mapping the data fields corresponding to the dose order to the client input fields, the conversion module (130) can also perform conversions on the data included in each of the fields. As a result, the data within each of the fields may be converted into the format or form expected by the client in a given client information field. For example, see further FIG. 17. A user interface (1700) is provided, which includes representations of potential conversions to be performed by the conversion module (130). The user interface (1700) can include the following: a type listing (1710), a client form listing (1720), and an EMR form listing (1730). These may be provided in a table (1702). In this regard, the table (1702) can include the following: a plurality of listings (e.g., arranged by type (1710)) for converting from the EMR form (1730) to the client form (1720). As can be understood, some of the listings may provide the same form for the EMR form (1730) and the client form (1720). For example, the form corresponding to the listing (1712) for "Acetate" may be the same in the EMR form (1732) and the client form (1722). However, as may be understood from the listing (1702), for other forms, they may be different between the EMR form (1730) and the client form (1720). For example, for the listing (1714), in the EMR form, it may be "ADULTTRACE", and in the client form (1724), it may be "Adult Trace Conc". Therefore, if the EMR form (1734) regarding the listing (1714) is represented in the data field regarding the staging table, the data can be converted by the conversion module (130) into the client form (1724).In this regard, the user interface (1700) can also include the following: a type filter (1740) and a client form filter (1750). These can be used to narrow down the results presented in the table (1702). Further, when a given listing in the table (1702) is selected, the EMR form (1730) for the given listing can be modified using the EMR form input (1760). For example, for a given portion of data, when a listing is selected from the table (1702), the EMR form (1730) for the listing can be modified using the EMR form input (1760). Further, listings can be added or deleted from the listing (1702) by the user. In this regard, it should be understood that the user can manage the definitions provided within the listing (1702), which pertain to the conversions to be applied by the conversion module (103), and such management can be performed using the user interface (1700). In this regard, the user interface (1700) may be provided by the web page (312) of the platform interface module (120) and / or by the dose execution client (140) including the conversion module (130) (as described above).

[0086] See also FIGS. 10-12. An example of the processing of a dose order from an EMR system (110) to a dose execution client (140) is depicted. Specifically, FIG. 10 depicts a text representation of a data stream (600) from which a dose order is identified. And FIG. 11 presents a text representation of a log managed by a conversion module (130), which log is for when acting on the identified dose order from the data stream (600). FIG. 12 represents the user interface (800) of the dose execution client (140), which client receives the dose order. In this regard, the text representation of the data stream (600) can include the following: a plurality of data fields. For example, the highlighted data fields correspond to the following: a patient data field (610), a dose order type field (620), a macro component detail field (630), and a micro component detail field (640). These are identified from the data stream (600) with respect to a given dose order. In this regard, metadata for each corresponding field can be stored in a staging table. For example, the metadata found within the patient data field (610) can be used to place one or more fields within a staging table related to the patient. Specifically, the name "TONI SMC", gender "female", date of birth "19871229", and EMR number "123456" can be identified within the patient data field (610). Further, an identifier indicating that the dose order is a TPN order can be identified from the dose order type field (620). Further, the macro component (630) "AMINOSYN II 15% IV SOLN^RX | 100.8|g|100.8|g" for the dose order (630) may be included within the macro component data field (630).Furthermore, the micro-components "SODIUM CHLORIDE 4 MEQ / ML IV SOLN^RX|33.6|MEQ|33.6|MEQ" and "POTASSIUM ACETATE 2 MEQ / ML IV SOLN^RX|16.8|MEQ|16.8|MEQ" can be specified in the micro-component details field (640).

[0087] Furthermore, with reference to the log (700) generated by the conversion module (130), the following points should be understood: namely, the conversion module (130) can convert the patient data field (610) into an input for the generation of a patient in the dose execution client (140) (for example, in this case, the ABACUS calculation software application) in row (710). Further, using the dose order type field (620), an input for the generation of an order in the dose execution client (140) can be generated in row (720). And an order for the dose execution client (140) can be arranged together with the inputs corresponding to the macro-component details (630) and the micro-component details (640). As a result, these data fields are represented within the order input data (734) of the dose execution client (140). As can be understood, the macro-component detail fields in the micro-component detail fields (630) and (640) may be converted into a format related to a unique input format related to the dose execution client (140). In this regard, the input fields (630') and (640') correspond to the macro-component detail field (630) and the micro-component detail field (640), but these fields can contain data in the converted format. And using the input for the dose execution client (140) reflected in the log (700), an input for the dose execution client (140) can be provided.

[0088] And, FIG. 12 shows the user interface (800) of the dose execution client (140), and the display is after receiving the command reflected in the log (700). As can be understood, the patient information file (10) may be presented together with the information corresponding to the data included in the patient data field (610). Specifically, the name of the patient, the EMR number, the age based on the date of birth, or other information provided in the patient data field (610) may be provided in the patient information field (810). Further, a component listing (820) of the dose execution client (140) can be provided. As can be understood, the macro component (830) listed in the component listing (820) corresponds to the data included in the macro component data field (630). The micro component (840) listed in the component listing (820) corresponds to the data included in the micro component data field (840). As can be understood, the forms of the components (830) and (840) may be different from those included in the data fields (630) and (640), and thus may reflect the conversion performed by the conversion module (130).

[0089] Refer further to FIG. 13, which depicts a user interface (900) for the dose execution client (140). The user interface (900) can include the following: a patient listing (910). The patient listing (910) may list patients for whom dose orders are pending. When receiving a dose order from the conversion module (130), the dose execution client (140) updates the patient listing (910) with a status indicator (912) to indicate receipt of the dose order. In this regard, the user interface (900) can further include the following: an order listing field (920). The order listing field (920) can list complete and pending dose orders for a given patient selected from the patient listing (910). As will be appreciated, a first pending order (922) and a second pending order (924) may be shown as having been received by the dose execution client (140). Status indicators for the received pending doses (922) and (924) may be provided. Specifically, a first status indicator (926) may be provided to indicate the following: that no exception occurred in connection with the processing of the first pending order (922) by the platform interface module (120) and / or the conversion module (130). In this regard, the first status indicator (926) can indicate the following: that the first pending dose order (922) is ready for execution by the dose execution client (140).

[0090] A second status indicator (928) provided with a second pending dose order (924) can indicate that an exception occurred during processing of the second pending dose order (924). Selecting the second pending dose (924) can provide the user with a dose details screen (950) depicted in FIG. 14. The dose details screen (950) can include: a patient information field (810) (as described above in connection with FIG. 12). Further, the dose details screen (950) can include: a component listing (820) (as described above in connection with FIG. 12). The dose details screen (950) can also include: an exception field (960). This field can list exceptions identified during processing of the dose order by the platform interface module (120) and / or the conversion module (130). For example, exceptions may be identified in connection with: unrecognized products, unrecognized values, and unrecognized units, and unrecognized data fields, or other associated errors and processing of the dose order. For example, in FIG. 14, an exception (962) can be provided, which may correspond to an error that occurred in connection with mapping the component “insulin” to the dose execution client (140). In this regard, the exception listing (960) can include: an EMR form, a substance description, a value, and a unit associated with the exception (962). Accordingly, the user can select the exception (962) and resolve the error associated with the exception. For example, in FIG. 15, the dose details screen (950) is shown. Here, the user added a further component (964) to the component listing (820) associated with the component targeted by the exception (962). In this regard, the user can flag the exception (962), and this flag can be processed by the dose execution client (140) and can be a flag as if the dose formulation had proceeded.

[0091] Furthermore, in FIG. 16, a user interface (1000) can be provided for use in resolving exceptions (e.g., exceptions (962) identified in FIGS. 14 and 15). For example, the exception (962) may be due to: an improper mapping between the EMR form for the drug "insulin" and the client input form associated with the dose execution client (140). That is, an error may have occurred in the mapping between the EMR form and the client input form. At this time, the platform interface module (120) and / or the conversion module (130A) for processing the data fields containing the data were related to the insulin for this dose order. In this regard, the user interface (1000) can enable the user to select a product (1002) for modification by the user interface (1000). Then, the user can modify the treatment record for the selected product (1002).

[0092] Specifically, the user interface (1000) can also include the following: an EMR-compatible field (1004). This field can be used at the dose execution client (140) to provide a corresponding EMR form for the product (1002). In this regard, the user can use the user interface (1000) to adjust mapping errors between the EMR form and the client form for the drug "insulin". And when further processing subsequent dose orders containing the ingredient "insulin", appropriate conversions can be provided. As a result, an exception (962) can be prevented from occurring in the subsequent order having the same product (1002) provided with the subsequent order. The user interface (1000) provides exception resolution at the dose execution client (140), but the exception may be flagged at the platform interface module (120) and / or the conversion module (130) in the appropriate user interface. And this interface may be provided to facilitate providing correct mapping and / or conversion for the products in the dose order in a manner similar to that discussed in relation to FIG. 16. That is, exception handling as described in relation to FIG. 16, recognizable from the dose execution client (140), can also be provided in relation to the platform interface module (120) and / or the conversion module (130). Further, processing specific to the ingredient can be performed using the user interface (1000), but making collective changes to the mapping between the EMR form (1730) and the client form (1720) can be facilitated by the user interface (1700) (as described above in relation to FIG. 17).

[0093] In the drawings and the above description, the present invention has been illustrated and described, but such illustrations and descriptions should be considered as exemplary and not restrictive of its features. For example, a certain specific embodiment described above can be adapted to other described embodiments and / or arranged in other ways. (For example, the elements of a process may be executed in a different order). Therefore, it should be understood that: namely, that only the preferred embodiments and their variations are illustrated and described, and that all modifications and changes falling within the scope of the idea of the present invention are desired to be protected.

Claims

**Claim 1** A method for automated conversion of healthcare information by a conversion module, the conversion being between a first form from an electronic medical record (EMR) system and a second form related to a dose execution client, the dose execution client being for compounding a dose according to a dose order of the health information data, The method comprising: Retrieving, by the conversion module, dose order metadata regarding a dose order from a staging table corresponding to the dose order, wherein the staging table has the dose order metadata disposed therein, the metadata being received from a healthcare information data stream in a first form from the EMR system, and the staging table includes a plurality of dose order data fields, each corresponding portion of the dose order metadata being disposed in a respective one of the fields; Converting the dose order metadata into a predefined second form corresponding to the dose execution client; and Providing the dose order metadata in the second form to the dose execution client, the providing being for executing a dose related to the dose order based on the dose order metadata. **Claim 2** The method according to claim 1, further comprising: Receiving, by a platform interface module, the healthcare information data stream from the EMR system, wherein the healthcare information data stream includes information related to the dose order; Identifying the dose order from the healthcare information data stream; Parsing, from the healthcare information data stream, the dose order metadata for the dose order, wherein the dose order metadata includes one or more dose characteristics related to the dose order; and Disposing, by the platform interface module, the dose order metadata for the dose order in the staging table, wherein the staging table is stored in a staging table database. **Claim 3** The method according to claim 2, wherein the staging table stores the dose order metadata in a standardized intermediate format.

4. The method according to claim 3, further comprising: Receiving a first dose order in a first EMR form; Receiving a second dose order in a second EMR form; wherein the first dose order and the second dose order correspond to dose orders having the same constituent components, and wherein the form of the constituent components in the first EMR form is different from the second EMR form, and the form of the constituent components regarding the first dose order is the same as the form of the constituent components regarding the second dose order in their respective staging tables corresponding to the first dose order and the second dose order.

5. The method according to claim 1, further comprising: Identifying the dose execution client from a plurality of dose execution clients for execution of the dose order, at least partially based on the dose order metadata; wherein the plurality of dose execution clients each have a predefined second form; and the converting is at least partially based on the respective predefined second form of the identified dose execution client.

6. The method according to claim 5, wherein the staging table is independent of any of the plurality of dose execution clients.

7. The method according to claim 5, wherein the converting comprises: Mapping the plurality of dose order data fields of the staging table to the corresponding respective fields of a plurality of dose execution client input fields.

8. The method according to claim 7, wherein the dose execution client input fields are defined by a unique input format associated with the dose execution client.

9. The method according to claim 8, wherein the converting comprises: Verifying the dosing order metadata of the plurality of dosing order data fields with respect to the unique input format for the corresponding fields of the dosing execution client input fields. **Claim 10** The method according to claim 9, wherein the verifying includes the following: Associating the dosing order metadata of the plurality of dosing order data fields with the treatment record of the dosing execution client with respect to each corresponding field of the dosing execution client input fields. **Claim 11** The method according to claim 9, further including the following: Generating an exception in response to an error related to at least one of the mapping or the verification. **Claim 12** The method according to claim 11, wherein the exception includes prompting a human user to resolve the error. **Claim 13** The method according to claim 12, further including the following: Receiving input related to the resolution of the error from the human user, where the input includes at least one of the following: The correct mapping between the dosing order data fields of the staging table and the corresponding fields of the dosing execution client input fields, or the correct correlation between a part of the dosing order metadata and the treatment record of the dosing execution client. **Claim 14** The method according to claim 13, further including: Updating at least one of the mapping logic or the correlation logic for use in the mapping and the association, respectively, based on the input received from the human user. **Claim 15** The method according to claim 1, further including: Updating the staging table to indicate that the dosing order metadata for the dosing order has been retrieved by the dosing execution client. **Claim 16** The method according to claim 1, further including: Managing the dosing order record before providing the dosing order metadata in the second form to the dosing execution client. **Claim 17** The method according to claim 16, wherein the managing includes the following: Providing a user interface to enable a user to perform a management function for the dose order.

18. The method according to claim 17, wherein the management function includes at least one of the following: the method Changing dose order metadata, canceling the dose order, organizing the dose order with respect to other dose orders, or prioritizing the dose order with respect to other dose orders.

19. The method according to claim 1, further including the following: the method Performing logistic processing on the dose order.

20. The method according to claim 19, wherein the logistic processing includes performing an operation on the dose order after receiving the dose order in response to receiving an EMR system message. The method

21. The method according to claim 20, wherein the EMR system message includes at least one of the following: the method A dose order change message or a dose order cancellation message.

22. The method according to claim 21, wherein the logistic processing includes determining: whether the dose order metadata has been provided to the dose execution client; and The logistic processing is at least partially based on the determination. The method

23. The method according to claim 22, wherein the logistic processing includes performing an operation on the dose order record, the dose order record corresponding to the EMR system message, and the message relates to a dose order record that has not yet been provided to the dose execution client. The method

24. The method according to claim 23, wherein the logistic processing includes providing data to the dose execution client associated with the EMR system message, and the message relates to a dose order record that has been provided to the dose execution client. The method

25. The method according to claim 25, wherein the data provided to the dose execution client associated with the EMR system message is converted into a form corresponding to the dose execution client. The method

26. The method according to claim 1, wherein the dose execution client includes at least one of the following: a pharmacy workflow management application for manual compounding of the dose order, an automated dose compounding device, an automated total parenteral nutrition (TPN) compounder, or a dose dispensing cabinet.

27. The method according to claim 1, wherein the EMR system includes a hospital information system (HIS), the method.

28. The method according to claim 27, wherein the healthcare information data stream includes a Health Level 7 (HL7) format, the method.

29. The method according to claim 1, further comprising the following, the method: Performing a logging operation on the actions taken on the dose order to generate a log regarding the actions taken on the dose order.

30. The method according to claim 29, wherein the logging operation includes the following, the method: Aggregating a plurality of logs generated for each different action taken on the dose order.

31. A method for automated exchange of healthcare information between an electronic medical record (EMR) system and a dose execution client for execution of a dose order, the method comprising: Receiving a healthcare information data stream by a platform interface module, wherein the healthcare information data stream includes information related to a dose order; Identifying the dose order from the healthcare information data stream; Parsing the dose order metadata related to the dose order from the healthcare information data stream, wherein the dose order metadata includes one or more dose characteristics related to the dose order; Placing the dose order metadata for the dose order in a staging table, wherein the staging table includes a plurality of dose order data fields, and corresponding respective portions of the dose order metadata are placed in the fields; Converting the dose order metadata into a predefined format corresponding to a specific dose execution client to generate converted dose order metadata; and Providing the specific dose execution client with access to the converted dose order metadata, where the dose execution client is operable to retrieve the converted dose order metadata from the staging table and execute the dose order based on the converted dose order metadata.

32. The method according to claim 31, wherein the staging table stores the dose order metadata in a standardized intermediate format.

33. The method according to claim 32, further comprising: Receiving a first dose order in a first EMR form; Receiving a second dose order in a second EMR form; wherein the first dose order and the second dose order correspond to a dose order having the same constituent components, and wherein the form of the constituent components in the first EMR form is different from the second EMR form, and wherein the form of the constituent components for the first dose order is the same as the form of the constituent components for the second dose order in the respective staging tables corresponding to the first dose order and the second dose order.

34. The method according to claim 31, further comprising: Identifying the dose execution client from a plurality of dose execution clients for execution of the dose order, at least partially based on the dose order metadata, each of the plurality of dose execution clients having a respective predefined input format; wherein the converting is at least partially based on the respective predefined input formats of the identified dose execution clients.

35. The method according to claim 34, wherein the staging table is independent of any of the plurality of dose execution clients.

36. The method according to claim 34, wherein the converting comprises: Mapping the plurality of dose order data fields of the staging table to the corresponding respective fields of the plurality of dose execution client input fields.

37. The method according to claim 36, wherein the dose execution client input field is defined by a unique input format related to the dose execution client, the method.

38. The method according to claim 37, wherein the converting includes the following: the method. Verifying the dose order metadata of the plurality of dose order data fields with respect to the unique input format for the corresponding fields of the dose execution client input fields.

39. The method according to claim 38, wherein the verifying includes the following: the method. Associating the dose order metadata of the plurality of dose order data fields with the treatment record of the dose execution client with respect to each corresponding field of the dose execution client input fields.

40. The method according to claim 39, further including the following: the method. Generating an exception in response to an error related to at least one of the mapping or the verification.

41. The method according to claim 40, wherein the exception includes prompting a human user to resolve the error, the method.

42. The method according to claim 41, further including the following: the method. Receiving input related to the resolution of the error from the human user, wherein the input includes at least one of the following: The correct mapping between the dose order data fields of the staging table and each corresponding field of the dose execution client input fields, or the correct correlation between a part of the dose order metadata and the treatment record of the dose execution client.

43. The method according to claim 42, further including the following: the method. Updating at least one of the mapping logic or the correlation logic for use in the mapping and the association respectively based on the input received from the human user.

44. The method according to claim 31, further including the following: the method. Updating the staging table to indicate that the dose order metadata for the dose order has been retrieved by the dose execution client.

45. The method according to claim 31, further comprising the following, the method: Managing the dose order record before providing the dose order metadata in the second form to the dose execution client.

46. The method according to claim 45, wherein the managing comprises the following, the method: Providing a user interface to enable a user to execute management functions for the dose order.

47. The method according to claim 46, wherein the management function comprises at least one of the following, the method: Changing dose order metadata, canceling the dose order, organizing the dose order with respect to other dose orders, or prioritizing the dose order with respect to other dose orders.

48. The method according to claim 31, further comprising the following, the method: Performing logistic processing on the dose order.

49. The method according to claim 48, wherein the logistic processing comprises performing an operation on the dose order after receiving the dose order in response to receiving an EMR system message, the method.

50. The method according to claim 49, wherein the EMR system message comprises at least one of the following, the method: A dose order change message or a dose order cancellation message.

51. The method according to claim 50, wherein the logistic processing comprises determining: whether the dose order metadata has been provided to the dose execution client; and The logistic processing is at least partially based on the determination, the method.

52. The method according to claim 51, wherein the logistic processing comprises performing an operation on the dose order record, the dose order record corresponding to the EMR system message, the message being related to a dose order record not yet provided to the dose execution client, the method.

53. The method according to claim 52, wherein the logistic processing comprises providing data to the dose execution client related to the EMR system message, the message being related to a dose order record provided to the dose execution client, the method.

54. The method according to claim 53, wherein the data provided to the dose execution client related to the EMR system message is converted into a form corresponding to the dose execution client.

55. The method according to claim 31, wherein the dose execution client includes at least one of the following: A pharmacy workflow management application for manual compounding of the dose order, an automated dose compounding device, an automated total parenteral nutrition (TPN) compounder, or a dose dispensing cabinet.

56. The method according to claim 31, further including: Performing a logging operation on the actions taken for the dose order to generate a log regarding the actions taken for the dose order.

57. The method according to claim 56, wherein the logging operation includes: Aggregating a plurality of logs generated for each different action taken for the dose order.

58. The method according to claim 31, wherein the healthcare information data stream is received from an electronic medical record (EMR) system.

59. The method according to claim 58, wherein the EMR system includes a hospital information system (HIS).

60. The method according to claim 59, wherein the healthcare information data stream includes a Health Level 7 (HL7) format.

61. A healthcare information exchange system for the exchange of healthcare information between an electronic medical record (EMR) system and a dose execution client for the execution of dose orders, the system including: A stream processing module that communicates operably with the EMR system and receives a healthcare information data stream from the EMR system. A staging table database that communicates operably with the stream processing module, the database being for storing a staging table, the table having dose order metadata disposed therein, the metadata being included in the healthcare information data stream, the module, wherein the staging table includes a plurality of dose order data fields, and corresponding respective portions of the dose order metadata are disposed in the fields; and A conversion module that is functionally disposed between the staging table database and the dose execution client, the conversion module, wherein the conversion module is operable to identify the dose execution client for use during the execution of a dose order, and to convert the dose order metadata into a predefined format corresponding to the dose execution client; wherein the predefined format defines dose order data fields and corresponding dose order metadata formats related to the dose execution client.

Images