Dose preparation data analysis

Abstract

To provide a data analysis tool used with respect to a multidimensional data set relating to dose order records.SOLUTION: Provided is selective and secure access to a set of aggregated multidimensional data comprising dose order records for generation of data analysis with respect to the dose order records. The aggregated data may correspond to a plurality of unaffiliated facilities. As such, when a user of a given facility attempts to access a data analysis tool, the user can be identified in relation to the facility of the user who is accessing the tool. Next, by using a data cube class definition from which all other data analytics data cubes inherit, the data analysis tool limits the data to be used in conjunction with user identification, to generate data analysis output to source data to which the user has authorization to view. The output may include, for example, reports, dashboards, tables, or the like.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] Related Applications This application claims priority to U.S. Provisional Patent Application No. 62 / 088,358, entitled "DOSE PREPARATION DATA ANALYTICS," filed December 5, 2014, the contents of which are incorporated herein by reference as if fully set forth.

[0002] The present invention relates generally to the field of medical data management, and more particularly to facilitating data analysis for use in dose order record information, such that, based on a facility, specific, restricted access to a multidimensional repository of data corresponding to users of tools and data associated with that facility is provided. [Background technology]

[0003] Healthcare facilities, such as hospitals, often provide dose order information to pharmacies in connection with requests to prepare dose order records for administration to patients. Traditional approaches to processing received dose orders at pharmacies include, for example, printing a physical label for each dose order to be prepared. Activities at the pharmacy related to the dose orders then rely on the use of physical labels for workflow management. In addition to the physical labels being prone to being lost, misplaced, or confused, pharmacy staff also have limited ability to organize, manage, or communicate the dose orders represented by the physical labels.

[0004] In addition to the limitations of traditional approaches related to the preparation of dose orders in pharmacies, the ability to quantify, track, and otherwise review pharmacy activity after dose order preparation was also limited. For example, the use of physical labels affixed to dose orders upon completion of preparation leaves no means to record or audit the activities performed in the pharmacy regarding a particular dose order without tedious manual recording of pharmacy activities. Manual recording of pharmacy activities is time-consuming, prone to errors, and unreliable, and therefore does not present a viable option for quantifying, tracking, and reviewing pharmacy activities. Second, valuable information about pharmacy activities was not visible to pharmacy or hospital administrators.

[0005] Pharmacy workflow management applications have been developed to assist in the preparation, tracking, organization, and documentation of dose orders prepared or that have been prepared by pharmacies and the like. For example, see commonly owned U.S. Patent Application Publication No. 14 / 022,415, filed September 10, 2013, entitled "MANAGEMENT, REPORTING AND BENCHMARKING OF MEDICATION PREPARATION," which is incorporated herein by reference in its entirety. In this regard, a dose order record containing received and / or added dose order information and / or dose order metadata can be generated and recorded at a facility that prepares a dose order for administration to a patient. Further, the dose order record can be stored on a central server in operative communication with multiple facilities. In this regard, dose order records from multiple facilities can be collectively stored on the central server (e.g., for purposes related to data backup, etc.). Summary of the Invention [Problem to be solved by the invention]

[0006] In view of the above, it is recognized that dose order information from multiple facilities stored in a central location (e.g., a central server) can be advantageously used to provide reports, metrics, etc. regarding the stored data associated with one or more facilities. Specifically, a data analysis tool can be provided in operative communication with the central server, which can access the data stored in the central server to provide data analysis (e.g., dynamic reports, etc.). Because the data analysis tool can access the data in the central server, it can provide such analysis associated with one or more facilities without each facility having to maintain an interface to the data analysis tool. Advantageously, however, it is also recognized that because the data in the central server can include data from multiple different facilities, providing selective access to such reports allows for centralized application of the data analysis tool while maintaining security and limited access to individuals from each of the facilities when accessing the data in the central server. [Means for solving the problem]

[0007] Thus, the present invention describes a medical data management system that provides the ability to provide data analysis tools for use in conjunction with multidimensional data related to dose order records. Specifically, the present invention contemplates enabling selective access to multidimensional datasets. For example, dose order records from multiple facilities can be collectively stored as a multidimensional dataset. A base data cube class definition can be created that uses the identity of a user accessing the tool to determine the subset of records to which the user has access. In this regard, the base cube class definition can have data dimensions that enable filtering of data records for presentation to a user in dynamically generated reports. In this regard, additional data cube class definitions can inherit from the base data cube class definition, such that a user can only retrieve report data that corresponds to data to which they are authorized to access.

[0008] In this regard, a first aspect includes a method for providing a user with selective access to a data analysis tool for processing a multidimensional dataset corresponding to dose order records used to provide the user with a data analysis related to a subset of the dose order records of the multidimensional dataset. The method includes storing a multidimensional dataset comprising information corresponding to a plurality of dose order records. The plurality of dose order records of the multidimensional dataset includes at least one indication of a facility corresponding to the dose order records. The multidimensional dataset includes dose order records corresponding to the plurality of facilities. The method further includes receiving user information from a user of one of the plurality of facilities. The user information is information indicative of a given facility at which the user is accessing the data analysis tool. The method also includes the data analysis tool accessing the multidimensional dataset to generate a dynamically generated report related to the subset of the multidimensional dataset corresponding to the given facility at which the user is accessing the data analysis tool. Additionally, the method includes presenting to the user, at a user interface, the dynamically generated report related to the subset of the multidimensional dataset corresponding to the given facility at which the user is accessing the data analysis tool.

[0009] A number of feature refinements and additional features are applicable to the first aspect. These feature refinements and additional features can be used individually or in any combination. Thus, each of the following features described can be, but need not be, used with other features or combinations of features of the first aspect.

[0010] For example, in one embodiment, the data analysis tool may include a plurality of data cube class definitions that can be applied to the multidimensional dataset to generate dynamically generated reports. The plurality of data cube class definitions may include a base cube class definition from which all others of the plurality of data cube class definitions depend. The base cube class definition may include at least one data dimension associated with at least one representation of a facility corresponding to the dose order record. The method may then include applying the base cube class definition to the multidimensional dataset based on user information representing a given facility from which the user is accessing the data analysis tool, and constructing a data cube based on the application that limits the data accessible to the user to a subset of the multidimensional dataset corresponding to the given facility from which the user is accessing the data analysis tool.

[0011] In some embodiments, constructing can further include performing at least one data transformation operation on a subset of the multidimensional dataset, the at least one data transformation operation being defined in the base cube class definition. The at least one data transformation can include automatically overwriting a first data field of each given dose order record in the subset with a second data field of each of the dose order records of the subset. The at least one data transformation can be applied only to a given type of dose order record. The type of dose order record can be a total parenteral nutrition (TPN) dose, the first data field can be a dose description field, and the second field can be a drug name field for the given dose.

[0012] In some embodiments, the method may further include invoking other dependent data cube class definitions from the base cube class definition to apply to a subset of the multidimensional dataset corresponding to a given facility from which the user is accessing the data analysis tool, and generating dynamically generated reports on the subset of the multidimensional dataset. In some embodiments, the plurality of data cube class definitions may include a parameter indicating whether a data cube constructed using the data cube class definition contains protected health information (PHI). The parameter may be dynamically generated based on at least one dimension of the data cube class definition.

[0013] In some embodiments, receiving may include receiving login information at a local server residing at a given facility where the user is accessing the data analysis tool to initiate a user session, authenticating the user to the central server based on the login information received at the local server, and adding session variables associated with the user session based on the authenticated user login information. The session variables may include user information indicative of the given facility where the user is accessing the data analysis tool. In this regard, the method, in at least some applications, may include a delegated authentication process that may include passing a token to the data analysis tool based at least in part on the session variables. The token may be compared to tokens available at the central server to determine whether the user should be granted access to the data analysis tool. Accordingly, if the token matches one of the available tokens, a token may be issued to the user, and the corresponding available token may be removed from the central server. In some applications, the session variables may include a role definition for the user that is generated based at least in part on the login information received by the user. The role definition may include an indication of the user's capabilities related to viewing reports, editing reports, viewing cube class definitions, editing cube class definitions, viewing pivot tables, editing pivot tables, viewing dashboards, and editing dashboards.

[0014] The method further includes logging user activity associated with the user's use of the data analysis tool. Logging can include recording information about the user and the user's use of the data analysis tool. Logging can include recording an identification of a dynamically generated report presented to the user. Logging can include recording whether the dynamically generated report presented to the user included protected health information (PHI). The multidimensional dataset can include an identification of the dose, data related to the dose preparation process, data related to the dose timing, data related to errors encountered during dose preparation, data related to product disposal, data related to drug use, data related to administered medications, and data related to drug interactions.

[0015] A second aspect includes a system for implementing a data analysis tool to process a multidimensional dataset corresponding to dose order records for data analysis regarding a subset of the dose order records of the multidimensional dataset. The system includes a central server in operative communication with a plurality of local servers, each local server located at a respective facility that prepares doses corresponding to the dose orders for administration to patients. The central server receives information regarding the dose order records corresponding to the dose orders from the local servers. The system also includes a database at the central server that stores a data structure comprising a multidimensional dataset including a plurality of dose order records received from the plurality of local servers. Each of the plurality of dose order records of the multidimensional dataset includes at least one indication of the facility from which the dose order record was received. The system can also include a local server interface in operative communication with the plurality of local servers to receive user information from at least one of the plurality of local servers from a user of one of the plurality of facilities. The user information is information indicative of a given facility from which the user is accessing the data analysis tool. The system can also include a data analysis interface that facilitates operative communication with the data analysis tool. The data analysis interface provides the data analysis tool access to the multidimensional dataset stored in the database and generates dynamically generated reports related to a subset of the multidimensional dataset corresponding to a given facility from which the user is accessing the data analysis tool based on user information received from the local server interface. The system also includes a user interface that presents to the user in the user interface the dynamically generated reports related to the subset of the multidimensional dataset corresponding to a given facility from which the user is accessing the data analysis tool.

[0016] A number of feature refinements and additional features are applicable to the second aspect. These feature refinements and additional features can be used individually or in any combination. Thus, each of the features described above in relation to the first aspect can be, but need not be, used with other features or combinations of features of the second aspect.

[0017] A third aspect includes a system for providing a user with selective access to a data analysis tool for processing a multidimensional dataset corresponding to dose order records used to provide the user with a data analysis regarding a subset of the dose order records of the multidimensional dataset. The system includes a central server in operative communication with a plurality of local servers, each local server located at a respective facility that prepares doses corresponding to the dose orders for administration to patients. The central server receives information regarding the dose order records corresponding to the dose orders from the local servers. The system also includes a database at the central server that stores a data structure comprising a multidimensional dataset including a plurality of dose order records received from the plurality of local servers. Each of the plurality of dose order records of the multidimensional dataset includes at least one indication of the facility from which the dose order record was received. The system also includes a local server interface in operative communication with the plurality of local servers for receiving user information from at least one of the plurality of local servers from a user of one of the plurality of facilities. The user information is information indicative of a given facility from which the user is accessing the data analysis tool. The system also includes a data analysis tool in operative communication with the database to access the multidimensional dataset stored in the database, and that generates dynamically generated reports related to a subset of the multidimensional dataset corresponding to a given facility at which the user is accessing the data analysis tool based on user information received from the local server interface. The system also includes a user interface that presents to the user at the user interface the dynamically generated reports related to the subset of the multidimensional dataset corresponding to the given facility at which the user is accessing the data analysis tool.

[0018] A number of feature refinements and additional features are applicable to the third aspect. These feature refinements and additional features can be used individually or in any combination. Thus, each of the features described above in relation to the first aspect can be, but need not be, used with other features or combinations of features of the third aspect. [Brief explanation of the drawings]

[0019] [Figure 1] FIG. 1 is a schematic diagram of one embodiment of a selective and secure data analysis system associated with aggregated multidimensional data sets from multiple facilities. [Figure 2] FIG. 2 is a schematic diagram of one embodiment of data flow associated with an exemplary facility for the system of FIG. [Figure 3] FIG. 3 is a schematic diagram of one embodiment of the operation of the selective and secure data analysis system. [Figure 4] FIG. 4 is a flow chart illustrating one embodiment of delegated user authentication for use in a data analysis system. [Figure 5] FIG. 5 is a screenshot of one embodiment of a Pharmacy Workflow Administration login screen. [Figure 6] FIG. 6 is a screenshot of one embodiment of the Pharmacy Workflow Management home screen. [Figure 7] FIG. 7 is a screenshot of one embodiment of a central pharmacy report screen. [Figure 8] FIG. 8 is a screenshot of one embodiment of a data analysis report list screen. [Figure 9] FIG. 9 is a screenshot of one embodiment of a data analysis report display screen. [Figure 10] FIG. 10 illustrates one embodiment of a data analysis tool configuration setup. [Figure 11] FIG. 11 illustrates one embodiment of a logging schema that can be used in connection with a data analysis tool. DETAILED DESCRIPTION OF THE INVENTION

[0020] The following description is not intended to limit the invention to the form disclosed herein. Consequently, variations and modifications commensurate with the following teachings, skill, and knowledge of the relevant art are within the scope of the present invention. The embodiments described herein illustrate known modes of carrying out the invention, and it is further intended that one skilled in the art may use the invention in this or other embodiments and with various modifications dictated by the particular application or use of the invention.

[0021] Referring to FIG. 1, a system 10 that facilitates selective and secure data analysis in a distributed environment as described herein is shown. The system 10 may include a central server 12. The central server 12 may be in operative communication with multiple facilities 14. For example, as shown in FIG. 1, the central server 12 may be in operative communication with a first facility 14A, a second facility 14B, and a third facility 14C. However, while three facilities 14A, 14B, and 14C are shown in FIG. 1 for illustrative purposes, it will be understood that fewer or more facilities 14 may be in operative communication with the central server 12, and that the three facilities 14A-14C shown in FIG. 1 are intended for illustrative purposes only.

[0022] Thus, in at least one embodiment, the facilities 14 may constitute unaffiliated, separate medical facilities 14 that may prepare medication doses for administration to patients. The central server 12 may be hosted by another separate, unaffiliated third party that may be separate from any of the facility 14 entities. For example, the central server 12 may be hosted and / or executed by an application provider that provides one or more client applications that the facilities 14 execute to facilitate the pharmacy workflow management application. Specifically, the central server 12 may be executed or hosted by an application provider that provides the pharmacy workflow management application to each facility 14.

[0023] In this manner, facilities 14A, 14B, and 14C may execute a pharmacy workflow management application that enables facilities 14A, 14B, and 14C to receive, process, configure, prepare, track, or otherwise manage dose orders prepared at each of facilities 14A, 14B, and 14C. In this regard, each facility 14 may generate dose order information related to the dose orders processed at each of facilities 14. Facilities 14 may then be in operative communication with central server 12 and may provide dose order data to central server 12.

[0024] In this regard, dose order data may include one or more classes of information regarding the dose order being processed. For example, dose order data may include information corresponding to a dose order received at a pharmacy (e.g., information entered by a physician order entry (POE) system, information received by a pharmacy information system (PhIS), etc.). Dose order data may also include data associated with and / or generated in connection with preparing the dose order. This information may include data regarding the products (e.g., drugs, pharmacy products, or hardware) used to prepare the dose order. As such, the information may include information regarding one or more drugs (or all drugs) used to prepare the dose, such as the National Drug Code (NDC), lot number, and expiration date. The information may also include preparation metadata, such as information related to the identity of personnel acting on the dose, time events associated with the dose, images related to dose preparation and / or verification, errors detected or occurred during dose processing, information related to the pharmacist's review of the dose, and tracking information regarding the dose in the pharmacy and / or administration environment. In short, dose order data may include any information related to a dose order or preparation of a dose order that is recorded, generated, added to, or otherwise associated with a dose order.

[0025] Additionally, the data analysis server 16 may be in operative communication with the central server 12. As described in more detail below, the data analysis server 16 may include data analysis tools that may be applied to the data of the central server 12, e.g., to generate dynamically generated reports for use in data analysis regarding the data applied by the data analysis tool at the central server 12. The data analysis tools may include data cube class definitions that define data configurations and transactions to be performed in connection with the data to facilitate the generation of dynamic reports for use in data analysis. Such data cube class definitions are described in more detail below. In any respect, it may be appreciated that the data cube class definitions may be applied to the data of the central server 12 to facilitate data analysis associated with the data provided by the data analysis tool when applied.

[0026] In this manner, users from each facility 14 can access data analysis tools provided by the analysis server 16 to invoke the data analysis tools for use in connection with data stored on the central server 12. While providing a data analysis server 16 in operative communication with the central server 12, as outlined above, can simplify the interface complexity of the system 10 (e.g., as opposed to providing a data analysis server connection directly at each facility), interfacing with the central server 12 may create a need to provide selective, secure access to data stored on the central server 12. Specifically, because the central server 12 can store data from multiple facilities 14, users from a given facility (e.g., a first facility 14A) may not be provided with access to data from other facilities (e.g., a second facility 14B or a third facility 14C). That is, selective access may be provided to users, such that users at a given facility may only be provided with access to data analysis related to data related to the facility from which the user is accessing the data analysis tools. In this regard, as described in more detail below, the system 10 can provide selective, secure access to data analysis tools associated with portions of data specific to the institution 14 accessing the data analysis tools.

[0027] While the following disclosure describes providing selective access on a facility-by-facility basis by determining the facility from which a user is accessing the data analysis tool, it is understood that a user accessing the tool from a given facility may be an organizational user. That is, multiple facilities may comprise an organization. Thus, a user accessing the tool from a given one of the facilities comprising the organization may be sufficiently entitled to access data from multiple facilities comprising the organization. Thus, although this specification potentially describes determining data access on a facility-by-facility basis, the system may be implemented such that data from the central server can be analyzed using the data analysis tool, as long as the user accessing the tool is sufficiently entitled to view and use the data.

[0028] FIG. 2 further illustrates a schematic diagram of system 10 showing the flow of information between portions of system 10. In FIG. 2, each instance of facility 14 may be provided with a user workstation 18 and a local server 22. While a single instance of facility 14 is shown in FIG. 2, it can be understood in conjunction with the disclosure of FIG. 1 that multiple facilities 14, each having a user workstation 18 and a local server, may undergo similar information flows as described in conjunction with the given facility 14 shown in FIG. 2. Furthermore, while a single user workstation 18 is depicted in operative communication with a local server 20, it can be understood that multiple user workstations 18 may be provided in operative communication with the local server 20 and may generally follow the description provided herein. The user workstation 18 may be in operative communication with the local server 20, and may exchange dose order data between the user workstation 18 and the local server 20. This data exchange includes the exchange of dose order information between a local dose order data repository 22 (e.g., stored in a database or the like at the local server 20) and the user workstation 18. This facilitates providing dose order information to the user workstation 18 for use in preparing doses, generating or capturing dose order information, reviewing prepared dose orders by a pharmacist, or other activities provided by the pharmacy workflow manager.

[0029] Local dose order data 22 may be provided from local server 20 to central server 12. In this regard, central server 12 may store aggregated local dose order data 24. For example, aggregated local dose order data 24 may include dose order data received from multiple facilities as shown in FIG. 1 . As can be appreciated, the dose order data in aggregated local dose order data 24 may include an indication of the facility (or organization) from which the data 24 originated. Data analysis server 16 may then include data cube class definitions 26. As described in more detail below, data cube class definitions 26 may define values, measures, calculated measures, indexes, or other data operations to be performed on the data at central server 12 to facilitate data analysis in conjunction with data analysis tools provided by data analysis server 16. In this regard, data cube class definitions 26 may be invoked in conjunction with data or a subset of data and provided to an aggregated local dose order data repository 24 located on central server 12.

[0030] As noted above, it is recognized that providing data analysis tools related to the aggregated data at the central server 12 provides the added efficiency of being able to maintain a single interface related to the central server 12, thereby eliminating the need to provide or maintain an interface between each given facility 14 and the data analysis server 16. In this manner, for example, the development of a new data cube class definition 26 can be provided to all users of the data cube without each facility 14 having to specifically develop that cube for their own use. However, in connection with performing data analysis on the aggregated local dose order data repository 24, it may be necessary to provide a mechanism that allows users from each of the facilities to access only the data on the central server 12 that the user is correspondingly entitled to view. Otherwise, data integrity for each individual facility 14 may be lost.

[0031] Therefore, as contemplated herein, a user authentication process is provided whereby a user is required to provide user information, which can then be used to determine the facility from which the user is accessing the data analysis tool. By determining the data the user is accessing based on user identification information, data corresponding to the facility (or organization) corresponding to the user can be appropriately restricted. Accordingly, FIG. 3 shows a schematic diagram of a process flow 100 depicted in relation to a system 10 that enables authenticating a user in connection with access to a data analysis tool provided by the data analysis server 16. User authentication also provides user identification information, which can be used to determine what data the user is accessing on the central server 12 for use in connection with the data analysis tool. In this regard, the process flow 100 can be used to appropriately restrict the data the user is accessing on the central server 12 in connection with the data analysis tool provided by the data analysis server 16. Because part of the user authentication can be performed on the local server 22 and / or the central server 12, separate from the data analysis server 16, the authentication process can be referred to as a delegated authentication process (described in more detail below). Thus, conventional data analysis tools may require direct access to a single data source for operations on that data source. However, in the presently described concept, the data source may actually comprise multiple aggregated data sources stored remotely from the data analysis server. In this manner, a delegated authentication process may enable access to remote data in such a way that appropriate data provides restricted access to appropriate users.

[0032] Initially, with reference to FIG. 3 , various user interface states associated with the user workstation 18 are referenced in relation to the user workstation 18. Accordingly, as will be appreciated by those skilled in the art, the user interface states may correspond to web pages, user interface screens, or other resources accessed via a network connection (e.g., a local area network or wide area network connection, etc.). In this regard, the user workstation 18 may be in operative communication with the local server 20, the central server 12, and / or the data analysis server 16 via one or more network connections. Web resources, such as web pages or other tools, may then be accessed at the user workstation 18 to provide the user interface states referenced in FIG. 3 . In any event, the user interface states referenced in FIG. 3 are provided at the user workstation 18 to enable a user to interact with the system 10, as will be described in more detail below. As such, the user workstation 18, at least in certain embodiments, may comprise a thin client operable to provide functionality provided by remote access via the user workstation 18.

[0033] The user workstation 18 may initially display a pharmacy workflow administration login screen 28. An example of such a pharmacy workflow administration login screen 28 is shown in FIG. 5. In this regard, the login screen 28 presented to the user workstation 18 may include a username field 500 and a password field 502. The user may then enter a username in the username field 500 and a password in the password field 502. For example, each user of the facility 14 may be assigned a unique username and password combination that the service uses to identify the user for accessing the system 10. In this manner, the local server 20 contains a record of authenticated username and password combinations and may provide authenticated access to users attempting to access the system 10.

[0034] Thus, the username and password combination entered in username field 500 and password field 502 may include user authentication information. The provided user authentication information 38 may be communicated to local server 20. Local server 20 may then process the provided user authentication information (e.g., by referencing a record of authorized username and password combinations) to determine whether the user attempting to access system 10 is authorized to do so. If the user is so authenticated (e.g., the provided username and password combination matches an authorized username and password combination stored in a repository of local server 20), local server 20 may initiate a response 40 that includes information related to the pharmacy workflow home screen 30. Response 40 is provided to user workstation 18, resulting in the pharmacy workflow home screen 30 being displayed on user workstation 18.

[0035] With further reference to FIG. 6 , an example of a pharmacy workflow administrator home screen 30 is shown. As can be seen, the pharmacy workflow administrator home screen 30 may include multiple links related to functionality provided by the pharmacy workflow manager resident on the local server 20. In this context, the pharmacy workflow administrator home screen 30 may include a link 504 used to access administrative report resources provided by the central server 12. If a user then wishes to access the administrative reports, the user may click on the administrative report link 504. A request 42 is then provided to the local server 20 requesting access to the administrative report resources provided by the central server 12. The local server 20 may then provide authentication information 44 to the central server 12 corresponding to the user requesting access to the administrative reports. The authentication information 44 may be analyzed by the central server 12 to authenticate the user (e.g., based on username and password information provided during login 38, other information provided by the local server 20, user credential information managed by the central server 12, and / or other appropriate information).

[0036] Thus, the central server can use the authentication information 44 to authenticate that the user has appropriate authorization to access the management reporting tools at the central server 12. The central server 12 can then return an authentication key 46 to the local server 20. The local server 20 can then provide a redirect command 48 to the central server 12. Upon receiving the redirect command 48 at the central server 12, the central server 12 provides a redirection command 50 to the user workstation 18, redirecting the user workstation 18 to a central report screen 32 provided by the central server 12. An example of a central report screen 32 is shown in FIG. 7. The central report screen 32 can provide static reports related to the facility from which the user is accessing the central report screen 32. In this regard, the reports provided by the central report screen 32 need not be dynamic and / or may not provide data analysis tools separately provided by the data analysis server 16, as described in more detail below. Thus, as can be appreciated, once a local user is authenticated to the central server 12, the central report screen 32 can be provided directly from the central server 12.

[0037] Furthermore, once access to the data analysis server 16 is authenticated for a given user accessing the central report screen 32, a link 506 to an analysis tool can be provided. Selecting the link 506 on the central report screen 32 generates a request 52 for access to an analysis report listing page. In this regard, selecting the link 506 can provide the request 52 to the central server 12, requesting a listing of analysis reports from the central server 12. The central server 12 can then redirect the user to the data analysis report listing screen 34 by providing a redirect command 54 to the user workstation 18. An example of the data analysis report listing screen 34 is shown in FIG. 8. The data analysis report listing screen 34 can include multiple links 508 to different reports that can be provided by the data analysis server 16. For example, as described in more detail below, each of the different reports 508 can be provided by a different data cube class definition.

[0038] The data analysis report listing screen 34 may provide reports 508 in an organized format. In this regard, links 508 to reports may be provided in a report listing 510. The report listing 510 may include categories 512 that may be arranged into folders 514 for organization of the report links 508. Folders 514 may be created that may be specific to a given facility and / or a given user. In this regard, a user with appropriate responsibilities or roles may operate to save copies of data cubes and / or reports generated based on the data cubes in folders specific to the user or facility. In this regard, a user may operate to modify the resulting reports as desired when saving them in a folder. Modifiable reports may be saved in a private folder for access only by one or more predetermined users from a particular facility. Selecting a link for a report name 508 may provide a request 56 for the report to the central server 12.

[0039] Upon receiving the request 56 for the selected report 508, the central server 12 can provide authentication information 58 to the data analysis server 16 to authenticate the user. For example, the authentication information 58 can include, or be based at least in part on, user information provided in the login 38. Based on the user's authentication with the data analysis server 16, a data cube class definition corresponding to the selected report can be invoked and applied to the data at the central server 12. In this regard, the requested analysis report can have a corresponding data cube class definition maintained at the data analysis server 16 that can be provided to provide the requested analysis report. In this regard, the data cube class definition can be provided (60) to the central server 12 for application to data maintained at the central server 12 to facilitate providing the requested analysis report by communicating (64) the report to the data analysis report display screen 36. One such example of a data analysis report display screen 36 is shown in FIG. 9.

[0040] The data analysis report display screen 36 may be populated with the requested data analysis report 64 for transmission back to the user workstation 18. The example shown in FIG. 9 provides a bar graph 516 generated based on application of a data cube class definition corresponding to the report (e.g., in this case, "Detect Errors by Technician"). Additionally, filtering parameters 518 may be selected and applied (e.g., as defined by the data cube class definition used to generate the report) to further filter the data presented in the graph 516. In this regard, as can be appreciated, the reports displayed on the data analysis report display screen 36 may be dynamic in that a user may select various parameters to dynamically change the real-time presentation of the report. Other examples of reports that may be presented on the data analysis report display screen 36 may include charts, graphs, pivot tables (e.g., axes that are user-selectable in real-time using a data analysis tool), dashboards, or other data analysis tools. Furthermore, the ability to view and / or modify these various parameters associated with the report may be based at least in part on assigned role or resource privileges granted to the user during the user's authentication process.

[0041] As outlined above, reports that can be delivered for display on the data analysis report display screen 36 can be derived, at least in part, based on the application of data cube class definitions to data at the central server 12. The data cube class definitions can be used to create data cubes used to generate reports. A data cube is a multidimensional data structure used to aggregate data from related underlying data tables and / or data sources. While the term "cube" is used, a data cube may include four or more dimensions. As such, the use of the term "cube" does not limit a data cube to three data dimensions. Rather, a data cube can have dimensions that can correspond to related fields in database tables from which the data originates (e.g., including any of the fields described above related to dose order data), which can include three or more dimensions. Dimensions can be hierarchical (e.g., to provide drill-down capabilities in reports generated based on the data cube) and can have levels. Data cubes can also have measures that include data elements whose values ​​are based on the underlying data (e.g., resulting from the application of a function to the data). For example, measures such as average, sum, minimum, maximum, or other functions can be applied to generate the measures included in the data cube. In this regard, the measures may be provided in the underlying data source or may be calculated based on data in the underlying data source.

[0042] A data cube class definition can be developed to develop specific measures, dimensions, levels, values, indexes, or other tools used in the data analysis process. Once all of the measures, dimensions, values, indexes, etc. are defined for a data cube in a data cube class definition, the cube must then be compiled. Compiling defines the data in the form of a data cube and creates all the necessary classes required to access that data. The final step is building the data cube. Building the data cube adds data to all cube dimensions so that the data can be viewed and reported. In this regard, a batch job can be run periodically to synchronize data from source tables (e.g., data stored on the central server 12) into the data cube defined by the data cube class definition.

[0043] Once constructed, data cubes are static but can be used by users to generate dynamic reports (e.g., tables, charts, graphs, pivot tables, dashboards, etc.) based on the underlying data cube. A data analysis tool can have various levels of responsibility that can be used to perform various functions associated with the data analysis tool. For example, a user can be authorized to use a construction tool that allows the user to create data cube class definitions. Additionally, a user can be authorized to use an analysis tool that allows the user to create reports, pivot tables, or other analysis tools based on the constructed data cube. Furthermore, a user can use a viewing tool that displays results from predefined reports, pivot tables, dashboards, or other predefined analysis report outputs (designed by the analysis tool). An administrator access level can be provided to facilitate access to all levels, and other specific roles can be developed with privileges associated with multiple (but not necessarily all) levels of responsibility of the data analysis tool.

[0044] With further reference to FIG. 4, the system 10 may employ a delegated authentication process 400. The delegated authentication process 400 is illustrated in flowchart form in FIG. 4. The delegated authentication process 400 may delegate authentication of an authorized user who is sufficiently qualified to access the central server 12, such that, upon the central server 12 performing the delegated authentication, the analytic server 16 provides data analysis tools related to data stored on the central server 12. The process 400 may begin with a user logging into the local server 402. As described above, logging into the local server 402 may include providing a username and password. Similarly, the local server may contain a database of valid username and password combinations and may determine whether the user is authorized to access the local server. Upon successfully logging into the local server 402, the user may be presented with the option to request access to a reporting tool at the local server (404). Making the request for access to the reporting tool at the local server (404) redirects the user to a central server reporting page (406). In this regard, the central server may provide a web page for display to the user.

[0045] If the user has sufficient credentials to access the analysis report and / or if a central server report page is configured for the site from which the user is accessing the central server, the central server report page may include a link to the analysis report. When a user requests (408) an analysis report from the central server, the central server creates (410) an authentication token that is then stored in the central server's database. The central server may also invoke (412) a data analysis tool. When the data analysis tool is invoked (412), the created token (410) is passed to the data analysis server when the data analysis tool is invoked (412).

[0046] In this regard, when the data analysis server receives a request for access to a data analysis tool provided to the data analysis server, the data analysis server initiates (414) a cryptographic service provider to perform delegated authentication of the user access request to the data analysis tool. Specifically, the cryptographic service can contact a central server with information regarding the token received from the user access request. If the token matches a token provided in the central server's database, the user can be authenticated. The valid token can then be deleted (418) from the central server to prevent future use of that particular token without authentication. In this regard, when a user requests (408) access to an analysis report from the central server, a token is created (410) and stored on the central server. The user is redirected to invoke (412) the data analysis tool, and the corresponding created token is provided with the request. In this regard, when the data analysis server receives an authentication request, the cryptographic service provider can contact the central server to determine whether the token provided in the request matches one created in the database. In this regard, fraudulent requests to access the data analytics server using tokens that do not have corresponding tokens stored on the central server may not be authenticated, thus reducing the ability of unauthorized users to access the tool with fraudulent or expired tokens. In this regard, the token is analyzed by a cryptographic service provider to determine whether the requested user access is authorized (416). The user can then be recognized at the data analytics server (420) based at least in part on the authentication from the central server. That is, login information provided to the local server 402 can then be passed to the central server.

[0047] Additionally, the central server can provide user information to the data analysis server to identify the user (420). This information can include, for example, session variables that can identify the user, as described below, and / or information about roles and / or resources available to the user based on the user's entitlements. This can include defining the user and / or facility attempting to access the data analysis server. The data analysis server can then invoke a data analysis tool (422) based on the user identification, assigning roles and resources to the user attempting to access the data analysis server. In this regard, the appropriate data cube can be invoked (424) based on the user identification, which is then applied to the central server data based on the user identification. As described above, the appropriate data cube can filter the data at the central server so that a user from a given facility can access only data corresponding to that facility when using the data analysis tool. Furthermore, depending on the roles and resources assigned in (422), different ones of multiple data cubes can be provided to the user to run various different reports on the data. An analysis report can then be generated (426) based on the current data cube, and the report can be presented to the user (428).

[0048] Specifically, when identifying a user request for access to a data analysis tool provided by a data analysis server, authentication may include the user logging into the data analysis environment as a data analysis user with an appropriate role assigned. For example, during delegated authentication, the requesting user may: <customerid> | <userid> | <username>You can log in with a username in the format <customerid>is the customer ID (e.g., corresponding to the facility) for which the user is accessing the central report page. For example, the user identification can be provided as part of a session variable communicated to the data analysis server. 0 may be added to this field to support users who access data analysis directly from the central server using a customer ID, <userid>may be the user ID corresponding to the user (e.g., again using 0 to support users accessing the data analysis tool directly from the central server), and username may be the user's login ID. As an example, an administrator user with customer ID 5 and central server user ID 10 would log in as "5|10|Administrator".

[0049] Then, when accessing data to generate a report using a data analysis tool, user identification (e.g., as described above) can be used to limit the data to which the data cube class definition applies or to limit the data the user can access when generating a report. For example, in one embodiment, a base cube class definition can be provided from which all other data cube class definitions depend. In this regard, all data cube class definitions may inherit from the base cube class definition. To prevent unauthorized access from the local server, data cube class definitions for all data analysis tools developed inherit from the base cube class definition, which includes a special security filter class definition. In this regard, the base cube class definition may include an organization identifier and a customer identifier as default dimensions in addition to other dimensions included in the cube definition. The base cube class definition uses these two properties to include only records from a specific customer or organizational account based on the user identification information received during the user authentication process. This serves as a security mechanism to prevent users from accessing other customer data on the central server.

[0050] For example, to filter data on the central server based on a user's access to organization or site data, the base cube detects whether the user is an organization-level user or a site-level user. Based on that evaluation, a multidimensional filter string is constructed based on either the organization or site to which the user belongs. Once the filter string is constructed, the multidimensional filter is applied to all data within the base cube (which must include dimensions corresponding to organization ID or customer ID, for example) to limit the information the user sees in any report. In this way, the base cube class definition, in conjunction with the user identification information received during the authentication process, serves to limit a user's access to data corresponding only to the facility (or organization) to which the user belongs or from which the user is accessing the tool. In this way, a data analysis tool can operate on aggregated data corresponding to multiple facilities, while the base cube class definition, to which all other data cube class definitions depend, serves to limit access to data corresponding to the user's facility.

[0051] Because internal users (e.g., users accessing the data analysis tool directly from the central server) also need to be able to access data from the data analysis tool, the base cube class definition also detects whether the user is accessing the environment from the local server or directly using the central server. This can be achieved by determining whether the expected parameters have been added to the session variables for a given user session in which the user requests access to the data analysis tool. If so, the access is considered to be via the local server. If not, the access is considered to be via the central server screen, and a check is made of the roles belonging to the user session definition to ensure that the correct roles have been assigned to the user accessing the data analysis tool from the central server.

[0052] Additionally, a Protected Health Information (PHI) parameter can be used to indicate whether PHI information is exposed by a cube. This allows generated reports to identify cubes containing PHI information. Cubes containing PHI information can also require specific resources to be attributed to specific users accessing the cube. This limits access to pivot tables and dashboards derived from these cubes containing PHI. In this regard, a special concern with the exchange of health information includes maintaining patient privacy as it relates to the exchange of health information. For example, health information may include patient-identifying information (e.g., potentially including PHI). In this regard, the distribution of health information may be restricted by regulatory laws (e.g., the Health Insurance Portability and Accountability Act (HIPPA)) that may prohibit the transmission of health information involving PHI or other privacy concerns. While HIPAA may define PHI, it is understood that PHI, as used herein, includes not only data included in the HIPAA definition but also other data. For example, patient-identifying information (e.g., patient name, patient identification number, etc.) may be defined as PHI.

[0053] Additionally, data cube class definitions may include data transformations applied to data from data sources. These transformations may include generating measures that are calculated based on the underlying source data. Transformations may also include modifications to the source data. For example, in one particular example related to total parenteral nutrition (TPN) doses, specific dose order record fields may be acted upon by a corresponding data cube class definition. In this regard, during the build process, the data cube class definition may replace a given dose order field (e.g., a dose description field) with a value from another field (e.g., a dose drug name field). This transformation may only apply to specific dose types (e.g., TPN doses as determined by a record flag indicating whether the dose order is a TPN order or is based on the drug included in the order). In this way, during cube build, records from the source data table will be examined to determine whether the record contains the appropriate fields (e.g., "dose description," "TPN," and "dose drug name," following the example above). When a record is determined to be a TPN order to apply data transformations, the data analysis server can check the TPN field and, if the field is set to 1 (the dose is a TPN), copy the value of the field "Dose Drug Name" into the "Dose Description" field.

[0054] Additionally, each data cube class definition is such that when building data, the cube will not load records from sites that have been flagged as "data exclusion." In this regard, the base cube class definition determines whether a record is for a customer site that has a data exclusion designation, and if so, skips loading that record. Data exclusion designations 522 are set on the server details page 520 shown in FIG. 10.

[0055] In this regard, and with further reference to FIG. 10 , a server details page 520 is shown that allows for configuration of the behavior of the data analysis tool when accessed by various servers. In this regard, a list 524 of local servers that can provide user access to the data analysis tool is provided. For each server in the list 524, a server configuration field 526 is provided. In this field 526, details about the server (e.g., location address, server status, billing information, account number, server configuration details, etc.) can be configured. Specifically, an analysis access selection field 528 allows an administrator to set permissions associated with users from a given local server having access to the data analysis tool (e.g., thereby determining whether link 506 to the data analysis tool is provided in the central report screen 32 of FIG. 7 ). Furthermore, an analysis analyzer selection field 530 is provided that can be used to set permissions associated with users from a given local server having access to the analyzer of the data analysis tool (e.g., where reports, dashboards, pivot tables, etc. can be generated). Additionally, a data source list 532 can be provided associated with each specific data source for a given server in the list 524.

[0056] Returning to the reference to the data cube class definitions, certain useful data transformation techniques can be provided for use in the data cube class definitions. For example, a Protected Health Information (PHI) parameter can be provided (e.g., for all cubes) to identify whether the cube exposes PHI information. If the parameter indicating the presence of PHI is determined to be true, the cube contains PHI fields; otherwise, the cube is not considered to contain PHI fields. The PHI parameter can be dynamically generated based on the underlying data source to which the cube class definition is applied (e.g., whether the source data is determined to have PHI).

[0057] Additionally, a delta-time function can be provided. The delta-time function can be used to calculate the time difference between two times. Each time value can be passed as a parameter to the function, and the time difference (e.g., as measured in minutes, hours, days, seconds, etc.) can be returned as a dimension value. In this way, when a cube measure using a time function is created, a measure name can also be generated that indicates the time scale being extracted. For example, a measure called "DeliveredTimeMinutes" can be defined as the difference between the time a dose is delivered to a patient and the time it is received at the pharmacy. Continuing with this example, a data cube class definition with a cube scale "DeliveredTimeMinutes" can have instructions where a specific method call performs the actual calculation and the source data element is the time value to be compared. For example, a specific method call can return the difference between the defined time scales being compared and return that value as a positive integer.

[0058] Additionally, one or more custom time functions can be created. Custom functions can be created to evaluate any number of desired results. For custom time report functions that rely on multiple inputs to evaluate elapsed time, a custom time function can be provided that can take four time inputs and evaluate the dose preparation time based on a coding standard using the four input values. This method can take four defined time values ​​and perform a specialized calculation (e.g., evaluate the time dose at various stages of a process defined by the four input values).

[0059] Additionally, each data cube class definition can have record filtering, which allows unwanted records to be removed from the cube dataset. This can be thought of as similar to adding a WHERE clause to a SQL statement. In this regard, records can be excluded from the fact table when building the cube by setting up an "if" statement to determine whether the record should be included. For example, in one example, a data cube class definition can filter records based on the content of one or more predetermined dimensions in the cube (e.g., type and error category).

[0060] Additionally, a cube definition may include list tags that define the fields to display to a user when the user drills down in a pivot table or dashboard. A pivot table can have multiple defined lists. When defining a pivot table based on a cube, the pivot table designer can select which lists to display when an end user drills down on the pivot table. Dashboards based on that pivot table can also inherit the ability to drill down in the data to display the lists specified during pivot table design.

[0061] Additionally, the data cube class definition includes operations used to anonymize patient information contained within the data for a given data cube. For example, a hash function or the like may be applied to the patient information, thereby anonymizing the resulting data in the data cube. In further embodiments, the source data for a data cube class definition may be a data source from which patient identifying information has been removed (e.g., by a hash function or the like).

[0062] Additionally, when a user accesses a data analysis tool, log events can be generated that provide logging information about the user accessing the data analysis tool and various specific resources accessed during the session. In this regard, log entries can be generated (e.g., by logging modules at the central server 12 and / or the data analysis server 16) for a given user session and / or navigation occurring within the user session. These log entries can accomplish defining the user providing access for a particular session and can provide details about the user's specific navigation during the session. The user logs can then be reviewed to determine which user accesses which resources and specific parameters associated with that access. In this regard, a schema 600 corresponding to one embodiment of a user log is shown in FIG. 11.

[0063] 11 , the schema 600 used to generate log records may include a central user session log 610 created for each session by a user. A sub-record in the form of a central navigation log 620 may be generated for each central user session log 610 to track the user's specific navigation during the session corresponding to the central user session log 610. In this regard, session log records may be generated according to the schema for the central user session log 610. Accordingly, the session log 610 may include a property "browser information" as a string that stores the browser used by the user. The session log 610 may also include a property "CSP session ID" that corresponds to a reference to the cryptographic service provider session identifier used to engage in the logged user session (which may correspond, for example, to a token received from the user). The log 610 may also include a property "central user" that links to the user associated with this session. This may indicate a central user who accesses tools directly from the central server as a support user, if applicable. The log 610 may also include a property "client user" that contains a link from a client application to the user associated with this session. Log 610 may also include a property "Customer" that contains the identity of the customer for whom the user is accessing the tool. Log 610 may also include a property "Customer Client Info" that contains site statistics to obtain specific details about the client for whom the user is accessing the tool. Log 610 may also include a property "Entry Date" that contains the date the session was entered. Log 610 may also include a property "Entry Date / Time" that contains the date / time the session was entered. Log 610 may include a property "Last Active Date / Time" that corresponds to the date / time the session was last active or updated. Log 610 may include a property "Source" that provides information about the customer source if the user is redirected from the local server.Log 610 may also include a property "token" that corresponds to the uniquely identifiable token described above. Additionally, log 610 may include a property "web access type" that includes an identification of the particular application of the data analysis tool that was accessed.

[0064] Additionally, for each session log, a sub-record can be generated that includes a central navigation log 620 corresponding to the session activity or navigation. The central navigation log 620 may include properties such as a “Central User Session” property that links to the central user session log 610 associated with the logged navigation. The log 620 may also include a “Class Related URL” property that corresponds to the class being accessed. The property “Contains Patient Information” may indicate whether the resource being accessed (e.g., page, report, tool) contains PHI information. In this regard, if a report containing PHI is being run, the parameter “Contains PHI (HASPHI)” can be set to 1, or the report definition field “ContainsPHI” can be set to 1. The log 620 may also include a “Customer” property that indicates the customer from whom the user is accessing the tool. The property “Data Analysis Access” may indicate the resource from the data analysis tool being used (e.g., including the invoked data cube definition, etc.). The property "input date" may correspond to the date the session was entered, and the property "input date / time" may correspond to the date / time the session was entered. The log 620 may also include a property "report" that indicates the identification of the report being accessed, if any. The property "exported report" may include an indication of whether the report was exported. The property "report parameters" may also include parameters selected by the user when running the report or otherwise using the data analysis tool. The property "report query" may include an identification of the query executed to generate the report, and the "report record count" may include the records returned by the report. The property "server process time" may correspond to the processing time in ms (milliseconds). The property "source" may include an indication of the customer source if the user was redirected from the local server.

[0065] In connection with the foregoing discussion, it will be appreciated that the data analysis tools described herein can be used in a number of different contexts in connection with dose order data. Thus, while reference is made to dose order data throughout the present invention, such data can include and / or provide a wide range of data analysis. For example, as described above, the dose order data that can invoke the data analysis tools may include a number of different dose order data classes that can include information regarding dose orders, dosage order preparation, products used in dosage order preparation, or any other relevant information. In this regard, it will be appreciated that a number of different categories of data cube class definitions can be provided in the data analysis tools. Importantly, all such data cube class definitions can be subordinated to a base cube class definition that grants a facility (or organization) selective and secure access to specific data corresponding to a given user.

[0066] For example, multiple categories of data cube class definitions may be provided. For example, data cube class definitions may relate to general pharmacy workflow activities, pharmacy performance metrics, pharmacy exclusions, pharmacy usage and disposal, product and treatment related data, compliance data, and user logs, as examples. In this regard, example data cube class definitions in the general pharmacy workflow activities category may include data cube class definitions corresponding to dose orders, dose order items, dose preparation information, dose claim activity, dose scan events, dose verification history, and basic statistics regarding procedure summaries. In this regard, a DataCube class definition corresponding to basic dose statistics may include dose dimensions related to, for example, dose administration time, whether the dose was the first in a series, dose route (e.g., intravenous, oral, intramuscular, etc.), whether the dose is an unsafe dose, whether the dose is a high-risk dose, the nursing unit to which the dose corresponds, whether the dose is a STAT (rapid) dose, whether the dose is a total parenteral nutrition (TPN) dose, the type of TPN dose, whether the dose contains an unknown drug, the technician who prepared the dose, the workstation utilized for dose preparation, whether the dose is a stock dose, whether the dose is a diluted dose, dose status, dose preparation date, dose start time, and dose start minute. Additionally, any of the above dimensions may include normalized versions of the dimension (e.g., for normalized drug name, normalized amount, normalized units, etc.). Additionally, some data cube class definitions that provide dose order summary data include measures for total dose, final dose, QS (qualified) dose, QS diluent name, stock dose count, diluted dose count, number of dose reworks, inline dose verification, number of images per prepared dose, number of doses fully dispensed by pharmacist, number of manually added doses, number of doses requested, number of doses with broad (unapproved) drug name, number of doses by condition, number of doses by route, number of attachments for dose order recording, and normalized dose description.For a data cube class definition related to a dose order item, the data cube class definition may be associated with dimensions corresponding to the dose status (e.g., to filter our records of not actually delivered to the patient), dose description, official drug name, normalized dose description based on base unit and diluent, whether the dose is a stock dose, whether the dose is a diluted dose, whether the dose is an unsafe dose, whether the dose is a high-risk dose, total amount of the dose (e.g., including contributing small amount products), total final amount of the dose (e.g., as specified by the Electronic Medical Record System (EMR) or Hospital Information System (HIS) for the dose order), QS dose, and QS diluent name. A data cube class definition related to dose preparation information may include data dimensions corresponding to the preparation mode used to prepare the dose, the preparation mode option when the dose was prepared, and the calculated QS amount of the dose. A data cube class definition may be associated with the event of the pharmacist requesting the dose during validation (e.g., from another user who has a session verifying the dose). In this regard, a dose claim data cube class definition may include data dimensions corresponding to whether the dose was claimed during validation, whether the individual who claimed the dose disposed of the dose, the reason the claim succeeded or failed, whether the claim overrode another user's claim, the active time of the claim, the overriding user, the overridden user, and the dose identifier. A data cube class definition related to a dose scan event may include data dimensions related to the scan event name, the dose order identifier, the product lot identifier, the catalog identifier, the user identifier for the scan, and the event target (e.g., calculated to determine the dose order, product blog, or kit event type). A data cube class definition related to a dose verification history may include data dimensions corresponding to the user identifier of the user verifying the dose, the date / time the dose is verified, the verification result, the reason provided during verification (e.g., for requeue, cancellation, and rework), the dose identifier, the verification type, the dose disposition, the reason for reconstitution, and the rejected product log.A DataCube class definition related to procedure records may include dose entry date and time, dose completion date and time, user identifier of the technician used to prepare the dose, workstation identifier of the workstation used to prepare the dose, dose name, central authoritative procedure ID (e.g., corresponding to the procedure presented to the user at the time of preparation), procedure type, completed action count, required action count, total action count, and completion time.

[0067] Additionally, multiple performance data cube class definitions may be provided, which may include information regarding dose turnaround time and system performance. For a data cube class definition related to dose turnaround time, the data cube may include dimensions related to the workstation used to prepare the dose, preparation location name, technician name, patient location, nursing unit corresponding to the dose, dose priority, whether the dose is a STAT dose, whether the dose is an unsafe dose, number of items in the dose, whether the dose is a hold order, dose drug name, and preparation date / time. Furthermore, multiple measures may be provided for a data cube class definition related to dose turnaround time, including average preparation time, delivery time, preparation wait time, time to resume preparation after inline verification or rework, time to dispense the dose, average time to verify the dose, and average time to allocate the dose. A data cube class definition related to system performance may include data dimensions corresponding to log time / day, calculated record length of the session, function name, average data analysis server execution time, average client server execution time, longest data analysis server execution time, longest client server execution time, shortest data analysis server execution time, shortest client server execution time, and execution count.

[0068] Additionally, multiple data cube class definitions related to dose exceptions may be provided. Examples include data cube class definitions related to prevented errors (e.g., scan errors), detected errors, bypass reasons, dose order modifications, and alerts. Thus, prevented errors may correspond to errors (e.g., scan errors) automatically identified by the pharmacy workflow management application without human intervention, while detected errors may include errors identified by a human interacting with the pharmacy workflow management application, such as a pharmacist reviewing a dose. A data cube class definition related to scan errors may include data dimensions related to the dose, including the prevented error that occurred during dose preparation, the dose category, the dose identifier, the scanned barcode, the scanned official product information, the scanned product log information, the technician information, and the workstation information. A data cube class definition related to detected errors may include detected error data occurring at the pharmacist's review station. Data dimensions included within the detected error data cube class definition may include the reason for reconstituting the dose, the pharmacist information, the technician information, the workstation information, the preparation location, the nursing unit associated with the dose, the route of administration of the dose, whether the dose is an unsafe dose, the type of unsafe dose, whether the dose is a TPN order, and the dose description. A data cube class definition associated with a bypass reason may include information regarding the dose associated with a bypass print operation, whereby the dose order, when received by the pharmacy workflow management application, is bypassed to a label printer to print the dose order in a conventional format. Thus, the data dimensions of the bypass reason data cube class definition may include an indication that the dose was bypassed, the order entry date and time, drug information corresponding to the dose order, information regarding the source of the data order, etc.A data queue class definition related to dose order modifications may include data dimensions that include what dose modification was made, including updates to administration date / time, dose interruption, dose priority change, moving a dose to or from a held state, expiration date / time of a dose due to using inventory with an earlier expiration date, whether the dose was adjusted automatically by the system or intentionally by the user, the name of the person who made the modification, and the reason the modification was necessary (e.g., if the site is configured to enter a reason for the modification). A data cube class definition related to dose alerts may include data dimensions corresponding to whether the dose was alerted during the preparation process and other dose-identifying information that may allow trends related to dose alerts to be determined. Other data cube class definitions may include data dimensions related to received alerts (e.g., from within the pharmacy workflow management system or from external alert providers) regarding dose orders, patients, drugs, or some other piece of data that the pharmacy workflow management application stores.

[0069] Data cube class definitions can also relate to pharmacy usage and waste metrics. Examples may include data cube class definitions related to product waste, drug waste, and sister products. Thus, a product waste data cube class definition may include data dimensions corresponding to data from unused / expired products, such as product preparation location, preparation technician information, dose status, dose name, drug NDC code for the dose, total amount of the dose, current amount of the dose, expiration date of the dose, number of doses prepared, unused dose ratio (i.e., current amount divided by total amount), dose cost (e.g., as referenced from the official drug or product record associated with the dose), and whether the dose was a multiple-use dose. For example, a report derived from a product waste data cube generated from a product waste class definition may include an aggregation of the amount of drug wasted over a given period and / or the corresponding waste-related costs (e.g., using measures defined in the underlying data and / or data cube class definition). The drug disposal data cube class definition may include data dimensions corresponding to a product log identifier, an entry date, an expiration date, an activation date, the number of hours of overuse of the dose, the drug name, the amount of the dose, the dose unit, whether the dose is an unsafe dose, whether the dose is a high-risk dose, and whether the dose is a diluted dose. In this regard, the overuse hours data dimension may be a calculated measure that includes the difference between the expiration date and the activation date and time.

[0070] The Product and Therapeutic categories of data cube class definitions may include data cube class definitions related to Therapeutic Summary and Drug Combinations. Thus, a data cube class definition related to Therapeutic Summary may include data dimensions corresponding to the ability to look up instances of drug therapy in terms of average duration (e.g., number of days, number of doses, or total dose amount) including, for example, a customer identifier, a source identifier, a dose entry date, the drug name of the dose, a dose description, and a treatment ID. A Drug Combination data cube class definition may include a "crosstab" showing the frequency of drug combinations when given together. The data dimensions of this data cube class definition may include a customer identifier, a source identifier, a dose entry date, the drug name associated with the dose, the amount of the dose, the dose unit, and a dose identifier.

[0071] Multiple data cube class definitions can be related to compliance tracking. Examples include data cube class definitions related to planned task history and weight measurements. The planned task history data cube class definition can include data dimensions that can enable compliance tracking on planned tasks to be completed for a workstation. In this regard, data dimensions of the data cube can include workstation tasks, failed task dose counts (e.g., the number of bad doses due to clean tasks not being completed on time), completed task information (e.g., including user, time, workstation, whether the task is overdue, and the amount of time overdue), how many doses the user prepared on the overdue workstation, frequency type, frequency value, last completed date / time, last due date / time, and next due date / time. The weight measurements data cube class definition can include data corresponding to weight measurement recording dose preparation workstations. Furthermore, data queue class definitions related to compliance tracking can filter and / or search for doses based on multiple different data dimensions, such as dose type, dose preparation date, technician, location, or other suitable dimensions. Furthermore, dynamic reports generated based on compliance tracking can enable users to drill down through various dimensional levels. At a given level, the user may select and view individual dose order records that comprise a given data set (e.g., a chart cell or graphical portion may correspond to a given number of doses, which may manifest as a list of the specific dose order records referenced by that chart cell's graphical portion based on the user's selection). That is, reports may allow the user to select or define various parameters and provide the user with access to a list of doses that meet the criteria established by the user using the various parameter selections. The compliance tracking data cube may include links that allow the user to search for dose order logs that correspond to a given dose order contained in a list of specific dose order records.The dose order log may include any or all information about the selected dose order (e.g., data about the dose order record other than the data dimensions of the data cube used to filter or search for the dose order itself). That is, the dose order record includes any or all information about the dose order log even if that dose order information does not have a dimension included in the data cube used to obtain a link to access the dose order log for the dose order record. In an application, the dose order log that is linked to the compliance tracking data cube may correspond to a dose order log having a particular format and / or data content specified by an agency, such as a government regulatory agency, for use in determining regulatory compliance.

[0072] Additionally, multiple data cube class definitions can be associated with user logs. Examples may include web session-related data, workstation session-related data, central user session-related data, and central user navigation-related data and audit logs. A data queue class definition for web session information may include data dimensions corresponding to information related to a web-based user session, including, for example, the user's IP address, login date / time, logout date / time, browser name, browser version, browser extension installation version, session length, a breakdown between site configuration time and dose preparation function time, average server response time for web service requests, and average response time for web page requests. A data cube class definition related to workstation sessions may include data dimensions related to workstation login date / time, workstation logout date / time, workstation software version, workstation name, workstation location, user name accessing the workstation, and date / time of last activity. A data cube class definition related to central user sessions may include data dimensions corresponding to a central session log, session total time, and browser type / version. A queue class definition related to central user navigation can be based on the central navigation log. The audit log data class definition is operable to compare a complete snapshot of the audit log to identify which fields have changed.

[0073] Without limitation, other data cube class definitions can be provided that can leverage various data dimensions present in the dose order information. Furthermore, the source data for a data cube class definition can extend beyond dose order data. For example, additional data sources (e.g., located in hospital information systems, pharmacy information systems, laboratories, surgical data repositories, prescription records, national medical databases, etc.) can be accessed by data analysis tools. In this regard, data cube class definitions can be provided that reference such data sources. Additionally, data cube class definitions can be provided for use in constructing data cubes that reference multiple data sources (e.g., including dose order data and other data sources such as the hospital information systems, pharmacy information systems, laboratories, surgical data repositories, and national medical databases mentioned above). In any event, the aforementioned data cube class definitions can be used to construct corresponding data cubes. In this regard, one or more reports can be generated that reference the data cube to present the data to a user. The reports can take the form of pivot tables, dashboards, charts, graphs, or other report structures. The reports may be filterable (e.g., modifiable by users with appropriate roles and responsibilities) based on a variety of different data dimensions, such as dose order type, date, dose status, technician, pharmacist, or other data dimensions included in the data cube and defined in association with the report. Additionally, the reports may include drill-down based on the dimensional levels described above to provide more detailed data based on a given subset of the dimensional data. In this regard, users may be able to use the reports to identify trends, anomalies, patterns, or other information from the data presented in the dynamic report generated based on the data cube.

[0074] While the present invention has been illustrated and described in detail in the drawings and foregoing description, such illustration and description should be considered exemplary and not limiting in character. For example, the particular embodiments described above may be combined with other described embodiments and / or configured in other ways (e.g., process elements may be performed in other orders). Accordingly, it should be understood that only preferred embodiments and variations thereof have been shown and described, and that all modifications and changes that come within the spirit of the invention are desired to be protected.< / userid> < / customerid> < / username> < / userid> < / customerid>

Claims

1. 1. A method for providing a user with selective access to data analysis tools for processing a multidimensional dataset corresponding to dose order records used to provide a user with data analysis for a subset of the dose order records of the multidimensional dataset, the method comprising: storing a multidimensional dataset comprising information corresponding to a plurality of dose order records, wherein the plurality of dose order records of the multidimensional dataset include at least one indication of a facility corresponding to the dose order records, and wherein the multidimensional dataset includes dose order records corresponding to the plurality of facilities; receiving user information from a user at one of the plurality of facilities, wherein the user information is information indicative of a given facility from which the user is accessing the data analysis tool; The data analysis tool accesses the multidimensional dataset to generate a dynamically generated report regarding a subset of the multidimensional dataset that corresponds to the given facility from which the user is accessing the data analysis tool; and presenting to the user at a user interface a dynamically generated report regarding a subset of the multidimensional dataset corresponding to the given facility from which the user is accessing the data analysis tool; A method comprising:

2. The method of claim 1 , wherein the data analysis tool comprises a plurality of data cube class definitions that can be applied to the multidimensional dataset to generate the dynamically generated report.

3. The method of claim 2 , wherein the plurality of data cube class definitions comprises a base cube class definition from which all others of the plurality of data cube class definitions depend.

4. The method of claim 3 , wherein the base cube class definition includes at least one data dimension associated with the at least one representation of a facility corresponding to the dose order record.

5. applying the base cube class definition to the multidimensional dataset based on the user information indicating the given facility from which the user is accessing the data analysis tool; constructing a data cube based on said application that limits the data accessible to a user to a subset of said multidimensional dataset that corresponds to the given facility from which said user is accessing said data analysis tool; The method of claim 4 further comprising:

6. The constructing comprises: The method of claim 5 , further comprising performing at least one data transformation operation on a subset of the multidimensional data set, wherein the at least one data transformation operation is defined in the base cube class definition.

7. 7. The method of claim 6, wherein the at least one data transformation includes automatically rewriting a first data field of each predetermined dose order record in the subset with a second data field of each of the dose order records in the subset.

8. 8. The method of claim 7, wherein the at least one data transformation is applied only to predetermined types of dose order records.

9. 9. The method of claim 8, wherein the type of the dose order record is a total parenteral nutrition (TPN) dose, the first data field comprises a dose description field, and the second field comprises a drug name field for the prescribed dose.

10. Invoking other dependent data cube class definitions from the base cube class definition to apply to a subset of the multidimensional dataset corresponding to the given facility from which the user is accessing the data analysis tool, and generating the dynamically generated report on the subset of the multidimensional dataset. The method of claim 5 further comprising:

11. The method of claim 3 , wherein the plurality of data cube class definitions includes a parameter that indicates whether a data cube constructed using the data cube class definition contains protected health information (PHI).

12. The method of claim 11 , wherein the parameters are dynamically generated based on at least one dimension of the data cube class definition.

13. The receiving includes: receiving login information and initiating a user session at a local server resident at the facility where the user is accessing the data analysis tool; authenticating the user to a central server based on the login information received at the local server; and Adding session variables associated with the user session based on authenticated user login information. Further comprising: The method of claim 1 , wherein the session variables comprise the user information indicative of the given facility from which the user is accessing the data analysis tool.

14. 14. The method of claim 13, further comprising passing a token to the data analysis tool based at least in part on the session variables, and comparing the token with tokens available on a central server to determine whether the user should be allowed access to the data analysis tool.

15. 15. The method of claim 14, wherein if the token matches one of the available tokens, the token is issued to the user and the corresponding available token is removed from the central server.

16. The method of claim 13 , wherein the session variables include a role definition for the user that is generated based at least in part on the login information the user receives.

17. 17. The method of claim 16, wherein the role definition includes an indication of the user's capabilities related to viewing reports, editing reports, viewing cube class definitions, editing cube class definitions, viewing pivot tables, editing pivot tables, viewing dashboards, and editing dashboards.

18. The method of claim 1 , further comprising logging user activity in connection with the user's use of the data analysis tool.

19. The method of claim 18 , wherein the logging comprises recording information about the user and their use of the data analysis tool.

20. 20. The method of claim 19, wherein the logging comprises recording an identification of the dynamically generated report that is presented to the user.

21. 21. The method of claim 20, wherein the logging includes recording whether the dynamically generated report presented to the user contained protected health information (PHI).

22. 10. The method of claim 1, wherein the multidimensional dataset comprises data regarding dose identification, data regarding the preparation process of the dose, data regarding dose timing, data regarding errors made during dose preparation, data regarding product disposal, data regarding drug usage, data regarding administered medications, data regarding drug interactions, and data corresponding to alerts in a pharmacy workflow management application.

23. 1. A system for implementing a data analysis tool for processing a multidimensional dataset corresponding to dose order records for data analysis relating to a subset of dose order records of the multidimensional dataset, the system comprising: a central server in operative communication with a plurality of local servers, each local server located at a respective facility that prepares doses corresponding to the dose orders for administration to patients, the central server receiving from the local servers information regarding dose order records corresponding to the dose orders; a database at a central server storing a data structure comprising a multidimensional dataset including a plurality of dose order records received from the plurality of local servers, each of the plurality of dose order records in the multidimensional dataset including at least one indication of the facility from which the dose order record was received; a local server interface in operative communication with the plurality of local servers for receiving user information from at least one of the plurality of local servers from a user at one of the plurality of facilities, the user information being information indicative of a given facility from which the user is accessing a data analysis tool; a data analysis interface that facilitates operable communication with a data analysis tool, the data analysis interface providing the data analysis tool access to multidimensional datasets stored in the database and generating dynamically generated reports regarding a subset of the multidimensional dataset corresponding to the given facility from which the user is accessing the data analysis tool based on the user information received from the local server interface; a user interface that presents to the user the dynamically generated report on a subset of the multidimensional dataset that corresponds to the given facility from which the user is accessing the data analysis tool; and A system comprising:

24. 24. The system of claim 23, wherein the data analysis tool comprises a plurality of data cube class definitions applicable to the multidimensional dataset to generate the dynamically generated report.

25. 25. The system of claim 24, wherein the plurality of data cube class definitions comprises a base cube class definition from which all others of the plurality of data cube class definitions depend.

26. 26. The system of claim 25, wherein the base cube class definition includes at least one data dimension related to the at least one representation of a facility corresponding to the dose order record.

27. 27. The system of claim 26, further comprising a data analysis tool executing on a data analysis server in operative communication with the central server for applying the basic cube class definition to the multidimensional dataset based on the user information indicating a predetermined facility from which the user is accessing the data analysis tool, wherein the data analysis tool is operative to construct a data cube based on the application that limits data accessible to a user to a subset of the multidimensional dataset that corresponds to the predetermined facility from which the user is accessing the data analysis tool.

28. 30. The system of claim 27, wherein the data analysis tool is further operative to perform at least one data transformation operation on a subset of the multidimensional dataset, wherein the at least one data transformation operation is defined in the base cube class definition.

29. 29. The system of claim 28, wherein the at least one data transformation includes automatically rewriting a first data field of each predetermined dose order record in the subset with a second data field of each of the dose order records in the subset.

30. 30. The system of claim 29, wherein the at least one data transformation is applied only to predetermined types of dose order records.

31. 31. The system of claim 30, wherein the type of the dose order record is a total parenteral nutrition (TPN) dose, the first data field comprises a dose description field, and the second field comprises a drug name field for the prescribed dose.

32. 28. The system of claim 27, wherein the central server is further operative to invoke other data cube class definitions that depend from the base cube class definition to apply to a subset of the multidimensional dataset corresponding to the given facility from which the user is accessing the data analysis tool, and to generate the dynamically generated report on the subset of the multidimensional dataset.

33. 26. The system of claim 25, wherein the plurality of data cube class definitions includes a parameter that indicates whether a data cube constructed using the data cube class definition contains protected health information (PHI).

34. 34. The system of claim 33, wherein the parameters are dynamically generated based on at least one dimension of the data cube class definition.

35. 24. The system of claim 23, wherein the local server is operative to receive login information from the user accessing the data analysis tool to initiate a user session, wherein the local server is operative to communicate with the central server to authenticate the user to the central server based on the login information received at the local server, and the central server is operative to add session variables associated with the user session based on the authenticated user login information, the session variables including the user information indicating the given facility from which the user is accessing the data analysis tool.

36. 36. The system of claim 35, wherein the data analysis tool further comprises a cryptographic service operative to receive a token from a user attempting to access the server, wherein the token is based at least in part on the session variables added by the central server, and wherein the cryptographic service operative to compare the token with tokens available at the central server to determine whether the user should be allowed access to the data analysis tool.

37. 37. The system of claim 36, wherein if the token matches one of the available tokens, the system issues the token to the user and removes the corresponding available token from the central server.

38. 26. The system of claim 25, wherein the session variables include a role definition for the user that is generated based at least in part on the login information the user receives.

39. 39. The system of claim 38, wherein the role definition includes an indication of the user's capabilities related to viewing reports, editing reports, viewing cube class definitions, editing cube class definitions, viewing pivot tables, editing pivot tables, viewing dashboards, and editing dashboards.

40. 24. The system of claim 23, further comprising a logging module operable to log user activity relating to the user's use of the data analysis tool.

41. 41. The system of claim 40, wherein the logging includes recording information about the user and their use of the data analysis tool.

42. 42. The system of claim 41, wherein the logging comprises recording an identification of the dynamically generated report that is presented to the user.

43. 43. The system of claim 42, wherein the logging includes recording whether the dynamically generated report presented to the user contained protected health information (PHI).

44. 24. The system of claim 23, wherein the multidimensional dataset comprises data relating to dose identification, data relating to the dose preparation process, data relating to dose timing, data relating to errors made during dose preparation, data relating to product disposal, data relating to drug usage, data relating to administered medications, data relating to drug interactions, and data corresponding to alerts in a pharmacy workflow management application.

45. 1. A system for providing a user with selective access to data analysis tools for processing a multidimensional dataset corresponding to dose order records used to provide a user with data analysis relating to a subset of dose order records of the multidimensional dataset, the system comprising: a central server in operative communication with a plurality of local servers, each local server located at a respective facility that prepares doses corresponding to the dose orders for administration to patients, the central server receiving from the local servers information regarding dose order records corresponding to the dose orders; a database at a central server storing a data structure comprising a multidimensional dataset including a plurality of dose order records received from the plurality of local servers, each of the plurality of dose order records in the multidimensional dataset including at least one indication of the facility from which the dose order record was received; a local server interface in operative communication with the plurality of local servers for receiving user information from at least one of the plurality of local servers from the user at one of the plurality of facilities, the user information being information indicative of a given facility from which the user is accessing a data analysis tool; a data analysis tool in operative communication with the database to access the multidimensional dataset stored in the database, and which generates dynamically generated reports regarding a subset of the multidimensional dataset corresponding to the given facility from which the user is accessing the data analysis tool based on the user information received from the local server interface; a user interface that presents to the user the dynamically generated report on a subset of the multidimensional dataset that corresponds to the given facility from which the user is accessing the data analysis tool; and A system comprising:

46. 46. ​​The system of claim 45, wherein the data analysis tool comprises a plurality of data cube class definitions applicable to the multidimensional dataset to generate the dynamically generated report.

47. 47. The system of claim 46, wherein the plurality of data cube class definitions comprises a base cube class definition from which all others of the plurality of data cube class definitions depend.

48. 48. The system of claim 47, wherein the base cube class definition includes at least one data dimension related to the at least one representation of a facility corresponding to the dose order record.

49. 49. The system of claim 48, wherein the data analysis tool is further operative to perform at least one data transformation operation on a subset of the multidimensional dataset, wherein the at least one data transformation operation is defined in the base cube class definition.

50. 50. The system of claim 49, wherein the at least one data transformation includes automatically rewriting a first data field of each predetermined dose command record in the subset with a second data field of each of the dose command records in the subset.

51. 51. The system of claim 50, wherein the at least one data transformation is applied only to predetermined types of dose order records.

52. 52. The system of claim 51, wherein the type of the dose order record is a total parenteral nutrition (TPN) dose, the first data field comprises a dose description field, and the second field comprises a drug name field for the prescribed dose.

53. 50. The system of claim 49, wherein the central server is further operative to invoke other data cube class definitions that depend from the base cube class definition to apply to a subset of the multidimensional dataset corresponding to the given facility from which the user is accessing the data analysis tool, and to generate the dynamically generated report for the subset of the multidimensional dataset.

54. 54. The system of claim 53, wherein the plurality of data cube class definitions include a parameter indicating whether a data cube constructed using the data cube class definition contains protected health information (PHI).

55. 55. The system of claim 54, wherein the parameters are dynamically generated based on at least one dimension of the data cube class definition.

56. 46. ​​The system of claim 45, wherein the local server is operative to receive login information from the user accessing the data analysis tool to initiate a user session, wherein the local server is operative to communicate with the central server to authenticate the user to the central server based on the login information received at the local server, and the central server is operative to add session variables associated with the user session based on the authenticated user login information, the session variables including the user information indicating the given facility from which the user is accessing the data analysis tool.

57. 57. The system of claim 56, wherein the data analysis tool further comprises a cryptographic service operable to receive a token from a user attempting to access the server, wherein the token is based at least in part on the session variables added by the central server, and wherein the cryptographic service operates to compare the token with tokens available at the central server to determine whether the user should be allowed access to the data analysis tool.

58. 58. The system of claim 57, wherein if the token matches one of the available tokens, the token is issued to the user and the corresponding available token is removed from the central server.

59. 57. The system of claim 56, wherein the session variables include a role definition for the user that is generated based at least in part on the login information the user receives.

60. 50. The system of claim 49, wherein the role definition includes an indication of the user's capabilities related to viewing reports, editing reports, viewing cube class definitions, editing cube class definitions, viewing pivot tables, editing pivot tables, viewing dashboards, and editing dashboards.

61. 46. ​​The system of claim 45, further comprising a logging module operable to log user activity relating to the user's use of the data analysis tool.

62. 62. The system of claim 61, wherein the logging comprises recording information about the user and their use of the data analysis tool.

63. 63. The system of claim 62, wherein said logging comprises recording an identification of the dynamically generated report presented to the user.

64. 64. The system of claim 63, wherein said logging includes recording whether the dynamically generated report presented to the user contained protected health information (PHI).

65. 46. ​​The system of claim 45, wherein the multidimensional dataset includes data regarding dose identification, data regarding the preparation process of the dose, data regarding dose timing, data regarding errors occurring during dose preparation, data regarding product disposal, data regarding drug usage, data regarding administered medications, data regarding drug interactions, and data corresponding to alerts in a pharmacy workflow management application.

Images