Dosage Modulation 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 Application This application claims priority to U.S. Provisional Patent Application No. 62 / 088,358, titled "DOSE PREPARATION DATA ANALYTICS," filed on December 5, 2014, the contents of which are hereby incorporated by reference in their entirety as if fully set forth herein.

[0002] The present invention generally relates to the field of medical data management, and more particularly, to facilitating data analysis for use in dosage order records, such that, for example, based on a particular facility, certain restricted access to a multidimensional repository of data corresponding to users of tools and data related to the facility is provided.

Background Art

[0003] Medical facilities such as hospitals often provide dosage order information to pharmacies in connection with the requirement to prepare dosage order records for administration to patients. Conventional approaches to processing dosage orders received at a pharmacy include, for example, printing physical labels for each dosage order to be prepared. Next, pharmacy activities related to the dosage order are premised on using the physical labels for workflow management. In addition to the physical labels being prone to being lost, misplaced, or confused, the ability of pharmacy staff to organize, manage, or communicate dosage orders indicated by the physical labels has also been limited.

[0004] In addition to the limitations of conventional approaches related to the preparation of dosage instructions at pharmacies, the ability to quantify, track, and otherwise reconsider pharmacy activities after the preparation of dosage instructions was also limited. For example, the use of physical labels attached to dosage instructions at the time of preparation leaves no means of recording or auditing the activities carried out at the pharmacy with respect to a particular dosage instruction without performing tedious manual records of pharmacy operations. Manual records of pharmacy operations are time-consuming, prone to misrecording, and unreliable, and thus do not present a viable option for quantifying, tracking, and reconsidering pharmacy activities. Next, valuable information regarding pharmacy activities was not visualized to pharmacy or hospital administrators.

[0005] A pharmacy workflow management application has been developed to assist in the preparation, tracking, composition, and documentation of dosage instructions prepared or that have been prepared by pharmacies and the like. For example, there is United States Patent Application Publication No. 14 / 022,415, entitled "MANAGEMENT, REPORTING AND BENCHMARKING OF MEDICATION PREPARATION," filed on September 10, 2013, which is hereby incorporated by reference in its entirety. In this regard, a dosage instruction record including received and / or added dosage instruction information and / or dosage instruction metadata can be generated and recorded at a facility that prepares dosage instructions for administration to patients. Further, the dosage instruction record can be stored in a central server that communicates operably with a plurality of facilities. In this regard, dosage instruction records from a plurality of facilities can be stored collectively in the central server (for purposes related to, for example, data backup, etc.). SUMMARY OF THE INVENTION PROBLEMS TO BE SOLVED BY THE INVENTION

[0006] In view of the above, it is recognized that it is possible to advantageously use dosage order information from a plurality of facilities stored in a central location (e.g., a central server) to provide reports, metrics, etc. regarding stored data related to one or more facilities. Specifically, a data analysis tool can be provided that communicates operably with the central server, and this data analysis tool can access the data stored in the central server to provide data analysis (e.g., dynamic reports, etc.). Since the data analysis tool can access the data of the central server, the analysis can be provided in relation to one or more facilities without the need for individual facilities to maintain an interface to the data analysis tool. Advantageously, however, since the data of the central server can include data from a plurality of different facilities, it is also recognized that by providing selective access to the reports, it is possible to centrally apply the data analysis tool while maintaining security and restricted access to individuals from each of the facilities when accessing the data of the central server.

Means for Solving the Problems

[0007] Thus, the present invention describes medical data management that confers the ability to provide a data analysis tool for use in relation to multidimensional data regarding dosage order records. Specifically, the present invention contemplates enabling selective access to a multidimensional data set. For example, dosage order records from a plurality of facilities can be collectively stored as a multidimensional data set. A basic data cube class definition can be generated, which uses the identification of the user accessing the tool to determine a subset of the records to which the user has access rights. In this regard, the basic cube class definition can have data dimensions that enable filtering of the data records to be presented to the user in a dynamically generated report. In this regard, additional data cube class definitions can be inherited from the basic data cube class definition, such that the user can only search for report data corresponding to the authenticated accessed data.

[0008] In this regard, a first aspect includes a method of providing a user with selective access to a data analysis tool for processing a multi-dimensional data set corresponding to dosage order records used to provide the user with data analysis regarding a subset of dosage order records of a multi-dimensional data set. The method includes storing a multi-dimensional data set comprising information corresponding to a plurality of dosage order records. The plurality of dosage order records of the multi-dimensional data set includes at least one indication of a facility corresponding to the dosage order record. The multi-dimensional data set includes dosage order records corresponding to a 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 that indicates a particular facility to which the user has access to the data analysis tool. The method also includes the data analysis tool accessing the multi-dimensional data set to generate a dynamically generated report regarding a subset of the multi-dimensional data set corresponding to the particular facility to which the user has access to the data analysis tool. Additionally, the method includes presenting the user with the dynamically generated report regarding the subset of the multi-dimensional data set corresponding to the particular facility to which the user has access to the data analysis tool via a user interface.

[0009] In the first aspect, improvements and additional features of a plurality of features are applicable. These improvements and additional features of the features can be used individually or in any combination. Thus, each of the following features described can be used with other features or combinations of features of the first aspect, but is not essential.

[0010] For example, in one embodiment, the data analysis tool can comprise a plurality of data cube class definitions applicable to a multidimensional data set to generate dynamically generated reports. The plurality of data cube class definitions can comprise a base cube class definition to which all of the other plurality of data cube class definitions are subordinate. The base cube class definition can include at least one data dimension related to at least one display of a facility corresponding to a dosage order record. Next, the method can include applying the base cube class definition to the multidimensional data set based on user information that displays a predetermined facility to which the user has access to the data analysis tool, and constructing, based on the application, a data cube that restricts data accessible to the user to a subset of the multidimensional data set corresponding to the predetermined facility to which the user has access to the data analysis tool.

[0011] In one embodiment, constructing can further include performing at least one data conversion operation in a subset of the multidimensional data set, and the at least one data conversion operation is defined by the base cube class definition. The at least one data conversion can include automatically rewriting a first data field of each predetermined dosage order record in the subset with a second data field of each of the dosage order records in the subset. The at least one data conversion can be applied to only a predetermined type of dosage order record. The type of dosage order record can be a total parenteral nutrition (TPN) dosage, the first data field can be a dosage description field, and the second field can be a drug name field for a predetermined dosage.

[0012] In one embodiment, the method can further include calling other data cube class definitions that are dependent from a basic cube class definition for application to a subset of a multi-dimensional data set corresponding to a given facility where a user is accessing a data analysis tool, and generating a dynamically generated report regarding the subset of the multi-dimensional data set. In one embodiment, the plurality of data cube class definitions can include a parameter indicating whether a data cube constructed using the data cube class definition includes protected health information (PHI). The parameter can be dynamically generated based on at least one dimension of the data cube class definition.

[0013] In one embodiment, receiving can include receiving login information at a local server resident at a given facility where a user is accessing a data analysis tool to initiate a user session, authenticating the user to a central server based on the login information received at the local server, and adding session variables related to the user session based on the authenticated user login information. The session variables can include user information indicating a given facility where the user is accessing the data analysis tool. In this regard, the method can include a delegated authentication process that can include, in at least some applications, passing a token to the data analysis tool based at least in part on the session variables. Compare the token to tokens available at the central server to determine whether the user should be permitted access to the data analysis tool. Thus, if the token matches one of the available tokens, the token can be issued to the user and the corresponding available token removed from the central server. In some applications, the session variables include a role definition for the user generated based at least in part on the login information received by the user. The role definition can 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 (recording) user activity in relation to the use of a data analysis tool by a user. Logging can include recording information regarding the user and the use of the data analysis tool by the user. Logging can include recording the identification of dynamically generated reports presented to the user. Logging can include recording whether a dynamically generated report presented to the user contained protected health information (PHI). The multidimensional dataset can include identification of dosages, data regarding dosage preparation processes, data regarding dosage timing, data regarding errors occurring during dosage preparation, data regarding product disposal, data regarding drug use, data regarding administered drug therapies, and data regarding drug interactions.

[0015] The second aspect includes a system for implementing a data analysis tool for processing a multi-dimensional data set corresponding to dosage order records for data analysis regarding a subset of dosage order records of a multi-dimensional data set. The system includes a central server operably communicating with a plurality of local servers, each local server being located at a respective corresponding facility that prepares dosages corresponding to dosage orders for administration to patients. The central server receives information regarding dosage order records corresponding to dosage orders from the local servers. The system also includes a database in the central server that stores a data structure comprising a multi-dimensional data set including a plurality of dosage order records received from the plurality of local servers. Each of the plurality of dosage order records of the multi-dimensional data set includes at least one indication of the facility from which the dosage order record was received. The system can also include a local server interface operably communicating 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 indicating a predetermined facility at which the user is accessing the data analysis tool. The system can also include a data analysis interface that facilitates operable communication with the data analysis tool. The data analysis interface provides access to the data analysis tool to the multi-dimensional data set stored in the database and generates a dynamically generated report regarding a subset of the multi-dimensional data set corresponding to the predetermined facility at which the user is accessing the data analysis tool based on the user information received from the local server interface. The system can also include a user interface that presents the user with the dynamically generated report regarding a subset of the multi-dimensional data set corresponding to the predetermined facility at which the user is accessing the data analysis tool through the user interface.

[0016] In a second aspect, improvements to a plurality of features and additional features are applicable. These improvements to the features and the additional features can be used individually or in any combination. Thus, each of the features described above in connection with the first alternative aspect can be used with, but is not required to 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 multi-dimensional data set corresponding to a dosage order record used to provide the user with data analysis regarding a subset of dosage order records of the multi-dimensional data set. The system includes a central server operably communicating with a plurality of local servers, each local server being located at a respective corresponding facility that prepares a dosage corresponding to a dosage order for administration to a patient. The central server receives information regarding dosage order records corresponding to dosage orders from the local servers. The system also includes a database in the central server that stores a data structure comprising a multi-dimensional data set including a plurality of dosage order records received from the plurality of local servers. Each of the plurality of dosage order records of the multi-dimensional data set includes at least one indication of the facility from which the dosage order record was received. The system also includes a local server interface operably communicating 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 indicating a particular facility at which the user is accessing the data analysis tool. The system also includes a data analysis tool operably communicating with the database to access the multi-dimensional data set stored in the database and generating a dynamically generated report regarding a subset of the multi-dimensional data set corresponding to the particular facility at which the user is accessing the data analysis tool based on the user information received from the local server interface. The system also includes a user interface for presenting the user with the dynamically generated report regarding a subset of the multi-dimensional data set corresponding to the particular facility at which the user is accessing the data analysis tool via the user interface.

[0018] In a third aspect, improvements to the plurality of features and additional features are applicable. These improvements to the features and additional features can be used individually or in any combination. Thus, each of the features described above in connection with the first aspect can be used with other features or combinations of features of the third aspect, but is not essential.

Brief Description of the Drawings

[0019]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Best Mode for Carrying Out the Invention

[0020] The following description is not intended to limit the present invention to the forms disclosed herein. As a result, changes and modifications associated with the following teachings, technologies, and knowledge of the related art are within the scope of the present invention. The embodiments described herein illustrate modes of knowledge in practicing the present invention, and it is further intended that those skilled in the art can use the present invention in these embodiments or other embodiments and with various modifications required by specific applications or uses of the present invention.

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

[0022] Accordingly, in at least one embodiment, the facility 14 can comprise an independent individual medical facility 14 that can prepare a dosage for administration to a patient. The central server 12 can be hosted by another independent and unrelated third party that may be separate from any of the entities of the facility 14. For example, the central server 12 can be hosted and / or executed by an application provider that provides one or more client applications executed by the facility 14 to facilitate a pharmacy workflow management application. Specifically, the central server 12 can be executed or hosted by an application provider that provides a pharmacy workflow management application to each facility 14.

[0023] In this way, facilities 14A, 14B, and 14C can execute a pharmacy workflow management application that can receive, process, configure, prepare, track, or otherwise manage dosage instructions prepared at each of facilities 14A, 14B, and 14C. In this regard, each facility 14 can generate dosage instruction information related to dosage instructions processed at each of the facilities 14. Next, the facility 14 may be operably communicable with the central server 12 and can provide dosage instruction data to the central server 12.

[0024] In this regard, the dosage instruction data may include one or more classes of information regarding the dosage instructions being processed. For example, the dosage instruction data may include information corresponding to dosage instructions received at the pharmacy (e.g., including information input by a physician order entry (POE) system, information received by a pharmacy information system (PhIS), etc.). The dosage instruction data may also include data associated with and / or generated in connection with the preparation of the dosage instructions. This information may include data regarding the products (e.g., drugs, pharmacy products, or hardware) used to prepare the dosage instructions. Thus, the information may include information regarding one or more (or all) of the drugs used to prepare the dosage, 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 identification of the personnel acting on the dosage, time events related to the dosage, images related to dosage preparation and / or verification, errors detected or occurred during dosage processing, information related to the review of the dosage by a pharmacist, and tracking information regarding the dosage in the pharmacy and / or administration environment. In short, the dosage instruction data can include any information regarding the dosage instructions or the preparation of the dosage instructions that is recorded, generated, added, or otherwise associated with the dosage instructions.

[0025] In addition, the data analysis server 16 can communicate operably with the central server 12. As will be described in more detail below, the data analysis server 16 can be provided with data analysis tools applicable to the data of the central server 12. For example, the data analysis tools can generate dynamically generated reports used for data analysis regarding the data applied at the central server 12. The data analysis tools may include data cube class definitions that define data configurations and transactions executed in relation to the data to facilitate the generation of dynamic reports used for data analysis. The data cube class definitions will be described in more detail below. In any case, it can be recognized that applying the data cube class definitions to the data of the central server 12 can facilitate data analysis related to the data provided by the data analysis tools at the time of application.

[0026] In this way, users from each facility 14 can operate to access the data analysis tool provided by the analysis server 16 and call the data analysis tool for use in relation to the data stored in the central server 12. As outlined above, by providing an analysis server 16 that communicates operably with the central server 12, while simplifying the complexity of the interface of the system 10 (for example, as opposed to directly providing a data analysis server connection to each facility), the need may arise to provide selective and secure access to the data stored in the central server 12 through the interface with the central server 12. Specifically, since the central server 12 can store data from multiple facilities 14, there may be a case where a user from a given facility (for example, the first facility 14A) should not be provided with access to data from other facilities (for example, the second facility 14B or the third facility 14C). That is, selective access is provided to the user, and as a result, a user of a given facility can only be provided with access to data analysis related to data related to the facility to which the user is accessing the data analysis tool. In this regard, as will be described in more detail below, the system 10 can provide selective and secure access to a data analysis tool related to a part of the data specialized for the facility 14 accessing the data analysis tool.

[0027] The following disclosure describes providing selective access at a facility by determining the facility at which a user is accessing a data analysis tool. It can be understood that the user accessing the tool from a given facility may be an organizational user. That is, a plurality of facilities can constitute one organization. Thus, a user accessing the tool from a given facility among the facilities constituting an organization can have sufficient qualifications to access data from the plurality of facilities constituting the organization. Accordingly, although potentially described herein as a per-facility determination with respect to data access, the system can be run so that data on a central server can be analyzed using a data analysis tool as long as the user accessing the tool has sufficient qualifications to view the data and use the tool.

[0028] FIG. 2 further shows a schematic diagram of system 10 showing the flow of information between parts of system 10. In FIG. 2, a user workstation 18 and a local server 22 can be provided for each instance of facility 14. Although a single instance of facility 14 is shown in FIG. 2, in relation to the disclosure of FIG. 1, it can be understood that a plurality of facilities 14 each having a user workstation 18 and a local server can receive an information flow similar to that described in relation to the predetermined facility 14 shown in FIG. 2. Further, although a single user workstation 18 is depicted as being operably communicable with local server 20, a plurality of user workstations 18 may be provided to be operably communicable with local server 20, and it can be understood that it can generally follow the description provided herein. The user workstation 18 can be operably communicable with the local server 20 and can exchange dosage order data between the user workstation 18 and the local server 20. This data exchange includes the exchange of dosage order information between a local dosage order data repository 22 (e.g., stored in a database or the like on local server 20) and the user workstation 18. Thereby, it can be easily provided to the user workstation 18 dosage order information for use in the preparation of dosages, the generation or capture of dosage order information, the review of dosage orders prepared by pharmacists, or other activities provided by a pharmacy workflow manager.

[0029] The local dosage order data 22 can be provided from the local server 20 to the central server 12. In this regard, the central server 12 can store the aggregated local dosage order data 24. For example, the aggregated local dosage order data 24 may include dosage order data received from a plurality of facilities shown in FIG. 1. As can be understood, the dosage order data in the aggregated local dosage order data 24 may include an indication regarding the original facility (or organization) of the received data 24. Next, the data analysis server 16 may include a data cube class definition 26. As will be described in more detail below, the data cube class definition 26 can define values, measures, calculated measures, indexes, or other data operations performed on the data at the central server 12 to facilitate data analysis in relation to the data analysis tools provided by the data analysis server 16. In this regard, the data cube class definition 26 can be called in relation to the data or a subset of the data and provided to the aggregated local dosage order data repository 24 disposed at the central server 12.

[0030] As described above, providing data analysis tools related to the aggregated data at the central server 12 can bring about the incidental efficiency of maintaining a single interface related to the central server 12, and as a result, it is recognized that it is not necessary to provide or maintain an interface between each predetermined facility 14 and the data analysis server 16. Thus, for example, the development of a new data cube class definition 26 can be provided without the need for each facility 14 to specifically develop the cube for individual use by all users of the data cube. However, in relation to performing data analysis on the aggregated local dosage 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 of the central server 12 that the user has the qualifications to view. Otherwise, the data integrity regarding each individual facility 14 may be lost.

[0031] Accordingly, as contemplated herein, a user authentication process is provided whereby a user is required to provide user information and then this information is used to determine the facility at which the user is accessing the data analysis tool. Based on the user identification information, by determining the data the user is accessing, the data corresponding to the facility (or organization) to which the user corresponds can be appropriately restricted. Accordingly, FIG. 3 shows a schematic diagram of a process flow 100 related to a system 10 that enables a user to be authenticated in relation to access to a data analysis tool provided by a data analysis server 16. User authentication also provides user identification information and can use this user identification information to determine what data the user is accessing at the central server 12 for use in relation to the data analysis tool. In this regard, the process flow 100 can be used to appropriately limit the data that a user is accessing at the central server 12 in relation to the data analysis tool provided by the data analysis server 16. Since a part of the user authentication can be performed at a local server 22 and / or the central server 12 remote from the data analysis server 16, the authentication process can be called a delegated authentication process (described in detail below). Thus, in conventional data analysis tools, there may be a need to directly access a single data source for operations thereon. However, in the concept being described currently, the data source can actually comprise a plurality of aggregated data sources stored remotely from the data analysis server. Thus, the delegated authentication process can enable access to remote data in such a way that appropriate data provides restricted access to appropriate users.

[0032] First, with respect to FIG. 3, various user interface states associated with the user workstation 18 are referred to in connection with the user workstation 18. Thus, as will be understood by those skilled in the art, the user interface state can correspond to a web page, a user interface screen, 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 can operably communicate with the local server 20, the central server 12, and / or the data analysis server 16 via one or more network connections. Next, a web resource such as a web page or other tool can be accessed at the user workstation 18 to provide the user interface state referred to in FIG. 3. In any case, the user interface state referred to in FIG. 3 is provided at the user workstation 18 to enable the user to interact with the system 10, which will be described in detail later. Thus, the user workstation 18 can include a client that functions to provide the functions provided by remote access via the user workstation 18, at least in certain embodiments.

[0033] The user workstation 18 can first display a pharmacy workflow management login screen 28. An example of such a pharmacy workflow management login screen 28 is shown in FIG. 5. In this regard, a username field 500 and a password field 502 can be provided on the login screen 28 presented to the user workstation 18. Next, the user can enter a username in the username field 500 and a password in the password field 502. For example, each user of the facility 14 can be assigned a unique combination of username and password that the service identifies the user accessing the system 10. Thus, the local server 20 can include a record of the authenticated combination of username and password and can provide authenticated access to users attempting to access the system 10.

[0034] Accordingly, the combination of the username and password entered in the username field 500 and the password field 502 may include user authentication information. The provided user authentication information 38 can communicate with the local server 20. Next, the local server 20 can process the provided user authentication information (e.g., by referring to a record of the authenticated username and password combination) to determine whether the user attempting to access the system 10 is authenticated to do so. If the user is so authenticated (e.g., the provided combination of username and password matches the combination of authenticated username and password stored in the repository of the local server 20), the local server 20 can initiate a response 40 that includes information related to the pharmacy workflow home screen 30. The response 40 is provided to the user workstation 18, and as a result, the pharmacy workflow home screen 30 is displayed on the user workstation 18.

[0035] Referring further to FIG. 6, an example of a pharmacy workflow administrator home screen 30 is shown. As can be understood, the pharmacy workflow administrator home screen 30 may include a plurality of links related to functions provided by a pharmacy workflow manager resident on the local server 20. In this description, the pharmacy workflow administrator home screen 30 may include a link 504 used to access management report resources provided by the central server 12. Next, if a user wishes to access a management report, the user can click on the management report link 504. Next, a request 42 is provided to the local server 20 that requests access to management report resources provided by the central server 12. Next, the local server 20 can provide authentication information 44 corresponding to the user requesting access to the management report to the central server 12. The authentication information 44 can be analyzed by the central server 12 to authenticate the user (e.g., based on the username and password information provided during login 38, other information provided by the local server 20, user credential information management at the central server 12, and / or other suitable information).

[0036] Therefore, the central server can use the authentication information 44 to authenticate that the user has the appropriate permission to access the management report tool on the central server 12. Next, the central server 12 can return the authentication key 46 to the local server 20. The local server 20 can then provide the redirect command 48 to the central server 12. Upon receiving the redirect command 48 at the central server 12, the central server 12 provides the user workstation 18 with a redirection command 50 that redirects the user workstation 18 to the central report screen 32 provided by the central server 12. An example of the central report screen 32 is shown in FIG. 7. The central report screen 32 can provide a static report regarding the facility to which the user is accessing the central report screen 32. In this regard, the report provided by the central report screen 32 may not be dynamic and / or may not provide a data analysis tool separately provided by the data analysis server 16 as described in more detail below. Therefore, as can be understood, when the local user is authenticated with respect to the central server 12, the central report screen 32 can be provided directly from the central server 12.

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

[0038] The data analysis report list screen 34 can provide the reports 508 in a systematic format. In this regard, the links 508 to the reports can be provided in a report list 510. The report list 510 may include categories 512 that can be arranged in folders 514 for the configuration of the report links 508. Folders 514 that may be specific to a given facility and / or a given user can be generated. In this regard, the user can, in an appropriate duty or role, operate to save a copy of the data cube and / or a report generated based on the data cube in a folder specific to the user or the facility. In this regard, when saving to a folder, the user can operate to modify the resulting report as desired. The modifiable report can be saved in a private folder so that only a given one or more users from a specific facility can access it. Selecting the link for the report name 508 can provide the central server 12 with a request 56 to request the report.

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

[0040] On the data analysis report display screen 36, a requested data analysis report 64 to be returned to the user workstation 18 can be added. In the example shown in FIG. 9, a bar graph 516 generated based on the application of a data cube class definition corresponding to a report (for example, in this case, "Detect Errors by Technician") is provided. Further, filtering parameters 518 can be selected and applied (for example, 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 understood, the report displayed on the data analysis report display screen 36 may be dynamic in that the user can select various parameters to dynamically change the real-time presentation of the report. Other examples of reports that can be presented on the data analysis report display screen 36 may include charts, graphs, pivot tables (for example, axes that can be selected by the user in real time using a data analysis tool), dashboards, or other data analysis tools. Further, the ability to display and / or modify these various parameters related to the report can be at least partially based on the assigned role or resource privileges given to the user during the user authentication process.

[0041] As outlined above, the reports that can be distributed 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. Using the data cube class definitions, data cubes to be used for generating reports can be created. A data cube is a multi-dimensional data structure used to aggregate data from related underlying data tables and / or data sources. Although the term "cube" is used, a data cube may contain four or more dimensions. Thus, even when using the term "cube", the data cube is not limited to three data dimensions. Rather, a data cube can have dimensions corresponding to relevant fields within the database table of the source of the data (e.g., including any of the above-described fields related to dosage order data), which can include three or more dimensions. The dimensions can have levels that may be hierarchical (e.g., to provide a drill-down function in reports generated based on the data cube). A data cube can also have measures that include data elements that are values based on the underlying data (e.g., resulting from the application of functions to the data). For example, measures such as average, total, minimum, maximum, or other functions can be applied to generate 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 the data of the underlying data source.

[0042] It is possible to develop a data cube class definition and develop specific metrics, dimensions, levels, values, indexes, or other tools to be used in the data analysis process. Once all of the metrics, dimensions, values, indexes, etc. are defined for the data cube in the data cube class definition, it is then necessary to compile the cube. Compilation defines the data in the form of the data cube and creates all of the necessary classes required to access that data. The final step is to build the data cube. In the step of building the data cube, data is added to all cube dimensions, and as a result, the data can be browsed and reported on. In this regard, a batch job can be run periodically to synchronize data (e.g., data stored in central server 12) from the source table to the data cube defined by the data cube class definition.

[0043] Once constructed, the data cube is static, but users can use it to generate dynamic reports (e.g., tables, charts, graphs, pivot tables, dashboards, etc.) based on the underlying data cube. Data analysis tools can have various levels of responsibility for performing the various functions associated with the data analysis tool. For example, a user can be authenticated to use a construction tool that enables the creation of a data cube class definition. Additionally, a user can be authenticated to use an analysis tool that enables the creation of reports, pivot tables, or other analysis tools based on the constructed data cube. Further, a user can use a browsing tool to display 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 permissions associated with multiple (but not necessarily all) levels of responsibility of the data analysis tool.

[0044] Referring further to FIG. 4, the system 10 can use a delegated authentication process 400. The delegated authentication process 400 is shown in FIG. 4 in the form of a flowchart. The delegated authentication process 400 can authenticate an authenticated user who has sufficient qualifications to access the central server 12 in a delegated form. As a result, when the central server 12 performs the delegated authentication, the analysis server 16 provides data analysis tools related to the data stored in the central server 12. The process 400 can be started when the user logs in to the local server 402. As described above, logging in to the local server 402 may include providing a username and password. Similarly, the local server includes a database of valid username and password combinations and can determine whether the user is authenticated to access the local server. When the user successfully logs in to the local server 402, an option to request access to the report tool on the local server (404) can be presented to the user. When a request for access to the report tool on the local server is made (404), the user is redirected to the central server report page (406). In this regard, the central server can provide a web page to be displayed to the user.

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

[0046] In this regard, when the data analysis server receives an access request to a data analysis tool provided to the data analysis server, the data analysis server starts an encryption service provider (414) and performs delegated authentication of the user access request to the data analysis tool. Specifically, the encryption service can contact the central server and information regarding the token received from the user access request. If the token matches the token provided to the central server's database, the user can be authenticated. Next, the valid token is deleted from the central server (418) to prevent that specific token from being used in the future without authentication. In this regard, when the user requests access to the analysis report from the central server (408), a token is created (410) and stored in the central server. The user is redirected to call the data analysis tool (412), and the corresponding created token is provided with the request. In this regard, when the data analysis server receives an authentication request, the encryption service provider can contact the central server to determine whether the token provided in the request matches the one created in the database. In this regard, an unauthorized request to access the data analysis server using a token that does not have the corresponding token stored in the central server may not be authenticated, thus reducing the ability of an unauthorized user to access the tool with an invalid or expired token. In this regard, the encryption service provider analyzes the token to determine whether the requested user access is authenticated (416). Next, based at least in part on the authentication from the central server, the user can be recognized at the data analysis server (420). That is, the login information provided to the local server 402 can then be passed to the central server.

[0047] In addition, the central server can identify a user by providing user information to the data analysis server (420). This information includes, for example, session variables that can identify the user as described below, and / or information regarding roles and / or resources available to the user based on the user's qualifications. This includes defining the user and / or facility attempting to access the data analysis server. Next, based on user identification, roles and resources can be assigned to the user attempting to access the data analysis server from the data analysis server to invoke a data analysis tool (422). In this regard, an appropriate data cube can be invoked based on user identification (424), and this data cube is then applied to the central server data based on that user identification. As described above, the appropriate data cube can filter data at the central server so that a user from a given facility can only access data corresponding to that facility when using a data analysis tool. Further, depending on the roles and resources assigned in (422), different ones of a plurality of data cubes can be provided to the user to execute various different reports regarding the data. Next, an analysis report can be generated based on the current data cube (426), and the report can be presented to the user (428).

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

[0049] Next, when accessing data to generate a report using the data analysis tool, user identification (such as the one described above) can be used to restrict the data to which the data cube class definition is applied or the data that the user can access when generating a report. For example, in one embodiment, a basic cube class definition to which all other data cube class definitions are subordinate can be provided. In this regard, all data cube class definitions may be inherited from the basic cube class definition. To prevent unauthorized access from the local server, the data cube class definitions of all developed data analysis tools are inherited from a basic cube class definition that includes a special security filter class definition. In this regard, the basic cube class definition may include an organization identifier and a customer identifier as default dimensions in addition to the other dimensions included in the cube definition. The basic cube class definition uses these two properties to include only records from a specific customer or organization account based on the user identification information received during the user authentication process. This functions as a security mechanism to prevent the user from accessing other customer data on the central server.

[0050] For example, to filter the data of the central server based on a user's access to organizational or site data, the basic cube detects whether the user is an organizational-level user or a site-level user. Based on that evaluation, a multidimensional filter string is assembled based on either the organization or site to which the user belongs. Once the filter string is assembled, the multidimensional filter is applied to all the data within the basic cube (which, for example, should include dimensions corresponding to organizational IDs or customer IDs) to restrict the information a user sees in any report. Thus, the basic cube class definition serves to restrict a user's access to data corresponding only to the facility (or organization) to which the user belongs or to which the user has access to the tool, in relation to the user identification information received during the authentication process. Thus, while the data analysis tool operates on aggregated data corresponding to multiple facilities, the basic cube class definition, to which all other data cube class definitions are subordinate, can serve to restrict access to data corresponding to the user's facility.

[0051] Internal users (e.g., users who access the data analysis tool directly from the central server) also need to be able to access data from the data analysis tool, so the basic cube class definition also detects whether the user is accessing the environment from the local server or using the central server directly. This can be achieved by determining whether the expected parameters are 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. Otherwise, the access is considered to be via the central server screen, and a check of the roles belonging to the user session definition is performed to confirm whether the correct role is assigned to the user accessing the data analysis tool from the central server.

[0052] In addition, using protected health information (PHI) parameters, it is possible to display whether PHI information is being published by a cube. This enables the generated reports to identify cubes that contain PHI information. Cubes that contain PHI information can also require specific resources that belong to a particular user accessing the cube. This will restrict access to pivot tables and dashboards derived from these cubes that contain PHI. In this regard, a particular concern regarding the exchange of medical information is maintaining patient privacy. This is because it is related to the exchange of medical information. For example, medical information may include patient identification information (e.g., potentially including PHI). In this regard, the distribution of medical information may be restricted by regulatory laws that can prohibit the transmission of medical information involving PHI or other privacy-related matters (e.g., the Health Insurance Portability and Accountability Act (HIPAA) in the United States regarding the transfer of health insurance and associated responsibilities). HIPAA can define PHI, and at the same time, it can be understood that the PHI used here includes not only data included in the HIPAA definition but also other data. For example, patient identification information (e.g., patient name, patient identification number, etc.) can be defined as PHI.

[0053] Furthermore, the data cube class definition may include data transformations applied to the data from the data source. These transformations may include generating metrics calculated based on the underlying source data. The transformations may also include changes to the source data. For example, in a particular example related to total parenteral nutrition (TPN) dosages, certain dosage order record fields can be acted upon by the corresponding data cube class definition. In this regard, during the construction process, the data cube class definition can replace a given dosage order field (e.g., the dosage description field) with a value from another field (e.g., the dosage drug name field). This transformation can only be applied to a specific dosage type (e.g., the TPN dosage determined by a record flag indicating whether the dosage order is a TPN order or based on the drugs included in that order). Thus, during cube construction, records from the source data table are examined to determine whether the record contains the appropriate fields (e.g., "dosage description", "TPN", and "dosage drug name" according to the above example). If a record is determined to be a TPN order to which the data transformation applies, the data analysis server can check the TPN field and, if the field is set to 1 (the dosage is TPN), copy the value of the "dosage drug name" field to the "dosage description" field.

[0054] In addition, each data cube class definition is such that when constructing the data, the cube does not load records from sites designated with a "data exclusion" flag. In this regard, the basic cube class definition determines whether a record is for a customer site with a data exclusion designation and, if so, skips loading that record. The data exclusion designation 522 is set on the server details page 520 shown in FIG. 10.

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

[0056] Returning to the reference of the data cube class definition, specific useful data conversion techniques can be provided for use in the data cube class definition. For example, a protected health information (PHI) parameter can be provided (e.g., for all cubes) to identify whether the cube discloses PHI information. If it is determined that the parameter indicating the presence of PHI is true, the cube includes a PHI field, and if not, the cube is not considered to include a PHI field. The PHI parameter can be dynamically generated based on the data source that is the basis for applying the cube class definition (e.g., whether it is determined that the source data has PHI).

[0057] In addition, a delta time function can be provided. The delta time function can be used to calculate the time difference between two times. The value of each time can be passed as a parameter to the function, and the time difference (when measured in, for example, minutes, hours, days, seconds, etc.) can be returned as a dimensional value. In this way, when a cube scale using the time function is generated, a scale name for displaying the extracted time scale can also be generated. For example, a scale called "DeliveredTimeMinutes" can be defined as the difference between the time when the dose was delivered to the patient and the time it was received at the pharmacy. Continuing with this example, the data cube class definition with the cube scale "DeliveredTimeMinutes" can have instructions such that a specific method call performs the actual calculation and the time values for which the source data elements are compared. For example, a specific method call can return the difference of the defined time scales being compared and return that value as a positive integer.

[0058] Furthermore, one or more custom time functions can be generated. Custom functions can be generated to evaluate any number of desired results. For a custom time reporting function that depends on multiple inputs to evaluate elapsed time, a custom time function can be provided that takes four time inputs, which evaluates the dose preparation time based on a coded criterion using the four input values. This method can take four defined time values and perform calculations specific to them (for example, evaluate the time dose at various stages of a process defined by the four input values).

[0059] In addition, record filtering can be provided for each data cube class definition. As a result, record filtering can remove unnecessary records from the cube data set. This can be considered in the same way as adding a WHERE clause to an SQL statement. In this regard, records can be excluded from the fact table when constructing the cube by setting an "if" statement to determine whether a record should be included. For example, in one example, the data cube class definition can filter records based on the content of one or more predetermined dimensions within the cube (e.g., type and error category).

[0060] In addition, the cube definition may include a list tag that defines fields for display to the user when the user drills down within a pivot table or dashboard. The pivot table can have multiple defined lists. When defining a pivot table based on a cube, the pivot table designer can select the list to display when the end user drills down on the pivot table. A dashboard based on that pivot table can also inherit the ability to drill down into the data to display the list specified during pivot table design.

[0061] Furthermore, the data cube class definition includes operations used to anonymize patient information contained in the data for a given data cube. For example, applying a hash function or the like to patient information can thereby anonymize the resulting data within the data cube. In a further embodiment, the source data for the data cube class definition may be a data source from which patient identification information has been removed (e.g., by means of a hash function or the like).

[0062] In addition, when a user accesses a data analysis tool, a log event can be generated that provides logging information regarding the user accessing the data analysis tool and the various specific resources accessed during the session. In this regard, log entries can be generated for a given user session and / or navigation occurring within the user session (e.g., by a logging module at central server 12 and / or data analysis server 16). These log sessions can achieve defining the user by providing access to the accesses related to a specific session and can provide details regarding the specific navigation of the user during the session. Next, the user logs can be reviewed to determine which user accesses are accessing which resources and specific parameters related to that access. In this regard, a schema 600 corresponding to one embodiment of the user log is shown in FIG. 11.

[0063] Accordingly, referring further to FIG. 11, the schema 600 used to generate the log records may include a central user session log 610 created for each session by the user. Sub-records in the form of a central navigation log 620 may be generated for each central user session log 610 to track the specific navigation of the user during the session corresponding to the central user session log 610. In this regard, the session log records can 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 storing the browser used by the user. The session log 610 may also include a property "CSP session ID" corresponding to a reference to an encryption service provider session identifier used to engage in the logged user session (e.g., which may correspond to a token received from the user). The log 610 may also include a property "central user" linking to the user associated with this session. This can indicate, if applicable, a central user who directly accesses the tool from the central server as a support user from the central server. The log 610 may also include a property "client user" including a link from the client application to the user associated with this session. The log 610 may also include a property "customer" including the identification of the customer for whom the user is accessing the tool. The log 610 may also include a property "customer client information" including site statistics to obtain specific details about the client for which the user is accessing the tool. The log 610 may also include a property "input date" including the date on which the session was entered. The log 610 may also include a property "input date / time" including the date / time on which the session was entered. The log 610 may include a property "last active date / time" corresponding to the date / time when the session was last active or updated. The log 610 may include a property "source" providing information about the customer source if the user was redirected from the local server.The log 610 may also include a property "token" corresponding to the uniquely identifiable token described above. Further, the log 610 may include a property "web access type" including identification of a specific application of the accessed data analysis tool.

[0064] Furthermore, for each session log, a sub-record can be generated that includes a central navigation log 620 corresponding to session activity or navigation. The central navigation log 620 may include properties such as a property "central user session" that links to a central user session log 610 related to the logged-in navigation. The log 620 may also include a property "class-related URL" corresponding to the accessed class. The property "includes patient information" may indicate whether the accessed resource (e.g., page, report, tool) contains PHI information. In this regard, when a report containing PHI is executed, the parameter "includes PHI (HASPHI)" can be set to 1, or the report definition field "includes PHI (ContainsPHI)" can be set to 1. The log 620 may also include a property "customer" indicating the customer to whom the user is accessing the tool. The property "data analysis access" may indicate resources from the data analysis tool used (including, for example, the called data cube definition, etc.). The property "input date" can correspond to the date on which the session was input, and the property "input date and time" can correspond to the date / time on which the session was input. The log 620 may also include, if any, a property "report" indicating the identification of the accessed report. The property "exported report" may include an indication of whether the report has been exported. The property "report parameters" may also include the parameters selected by the user when running the report or otherwise using the data analysis tool. The property "report query" may include the 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" can correspond to the processing time in ms (milliseconds). The property "source" may include an indication of the customer source when the user is redirected from the local server.

[0065] In connection with the foregoing description, it can be understood that the data analysis tools described herein can be used in a plurality of different contexts in relation to dosage order data. Thus, while reference is made to dosage order data throughout the present invention, such data can encompass and / or provide a wide range of data analysis. For example, as described above, the dosage order data that can invoke the data analysis tool may include a plurality of different dosage order data classes that can include dosage orders, the preparation of dosage orders, information regarding products used during the preparation of dosage orders, or any other relevant information. In this regard, it can be understood that a plurality of different categories of data cube class definitions can be provided to the data analysis tool. Importantly, all such data cube class definitions can be subordinate to a basic cube class definition that permits selective and secure access to the particular data corresponding to a given user to a facility (or organization).

[0066] For example, a plurality of categories of data cube class definitions can be provided. For example, the data cube class definitions can be, by way of example, related to general pharmacy workflow activities, pharmacy performance metrics, pharmacy exclusions, pharmacy use and disposal, data related to products and treatments, compliance data, and user logs. In this regard, examples of data cube class definitions in the general pharmacy workflow activity category may include data cube class definitions corresponding to basic statistics regarding dosage instructions, dosage instruction items, dosage preparation information, dosage billing activities, dosage scan events, dosage verification history, and procedure summaries. In this regard, the data cube class definitions corresponding to basic dosage statistics may include, for example, dosage administration time, whether the dosage was the first dosage in a series of dosages, dosage route (e.g., intravenous, oral, intramuscular, etc.), whether the dosage is a critical dosage, whether the dosage is a high-risk dosage, the nursing unit corresponding to the dosage, whether the dosage is a STAT (urgent) dosage, whether the dosage is a total parenteral nutrition (TPN) dosage, the type of TPN dosage, whether the dosage contains an unknown drug, the technician who prepared the dosage, the workstation used for dosage preparation, whether the dosage is an inventory dosage, whether the dosage is a dilution dosage, dosage status, dosage preparation date, dosage start time, and dosage dimensions related to dosage start minutes. Further, any of the above dimensions may include a normalized version of the dimension (e.g., in the case of a normalized drug name, normalized amount, normalized unit, etc.). Further, some data cube class definitions that provide dosage instruction summary data include scales regarding total dosage amount, final dosage amount, QS (quantity sufficient) amount of dosage, QS diluent name, inventory dosage count, dilution dosage count, dosage rework number, in-line verification of dosage, number of images per prepared dosage, number of dosages fully compounded by the pharmacist, number of dosages added manually, number of dosages for which a charge was billed, number of dosages with an extended (unapproved) drug name, number of dosages by status, number of dosages by route, number of attachments for dosage instruction records, and normalized dosage description.Regarding the data cube class definition for dosage order items, the data cube class definition may be related to dimensions corresponding to dosage status (e.g., for filtering our records of not actually delivered to patients), dosage description, official drug name, basic unit, and diluent, normalized dosage description based on the above, whether the dosage is a stored dosage, whether the dosage is a diluted dosage, whether the dosage is a dangerous dosage, whether the dosage is a high-risk dosage, total amount of dosage (e.g., including contributing minor products), final total amount of dosage (e.g., when specified by an electronic medical record (EMR) or hospital information system (HIS) for a dosage order), QS dosage, and QS diluent name. The data cube class definition for dosage preparation information may include data dimensions corresponding to the preparation mode used for dosage preparation, preparation mode options at the time of preparing the dosage, and the calculated QS amount of the dosage. The data cube class definition may be related to the event that a pharmacist bills for a dosage during verification (e.g., from another user having a session for verifying the dosage). In this regard, the data cube class definition for dosage billing may include data dimensions corresponding to whether the dosage was billed during verification, whether the individual who billed the dosage disposed of the dosage, reasons for the success or failure of the billing, whether the billing overwrote the billing of another user, active time of the billing, user who overwrote, user who was overwritten, and dosage identifier. The data cube class definition for dosage scan events may include data dimensions related to the scan event name, dosage order identifier, product lot identifier, catalog identifier, user identifier for the scan, and event target (e.g., calculated to determine the dosage order, product blog, or kit event type). The data cube class definition for dosage verification history may include data dimensions corresponding to the user identifier of the user verifying the dosage, date / time when the dosage was verified, verification result, reasons provided during verification (e.g., for recall, cancellation, and rework), dosage identifier, verification type, disposal of the dosage, reasons for re-preparation, and rejected product log.The data cube class definition related to procedure recording may include the entry date and time of the dosage, the completion date and time of the dosage, the user identifier of the technician used for dosage preparation, the workstation identifier of the workstation used for dosage preparation, the dosage name, the central official procedure ID (e.g., corresponding to the procedure presented to the user during preparation), the procedure type, the completed action count, the required action count, the total action count, and the completion time.

[0067] In addition, a plurality of performance data cube class definitions are provided, which may include information on the turn-around time of the dosage and system performance. For the data cube class definition related to the dosage turn-around time, the data cube may include the workstation used for dosage preparation, the preparation location name, the technician name, the patient location, the nursing unit corresponding to the dosage, the priority of the dosage, whether the dosage is a STAT dosage, whether the dosage is a critical dosage, the number of items in the dosage, whether the dosage is a storage order, the dosage drug name, and dimensions related to the preparation date / time. Further, a plurality of metrics may be provided for the data cube class definition related to the dosage turn-around time, including the preparation average time, the delivery time, the preparation waiting time, the time to resume preparation after in-line verification or rework, the time to dosage distribution, the average time for dosage verification, and the average time for dosage allocation. The data cube class definition related to system performance may include data dimensions corresponding to the log time / day, the calculated record length of the session, the function name, the average execution time of the data analysis server, the average execution time of the client server, the longest execution time of the data analysis server, the longest execution time of the client server, the shortest execution time of the data analysis server, the shortest execution time of the client server, and the execution count.

[0068] Furthermore, a plurality of data cube class definitions related to dosage exceptions can be provided. By way of example, data cube class definitions related to prevented errors (e.g., scan errors), detected errors, reasons for bypass, dosage order corrections, and alerts can be cited. Thus, a prevented error can correspond to an error (e.g., a scan error, etc.) automatically identified by a pharmacy workflow management application without human intervention, and detected errors may include errors identified by a human involved with the pharmacy workflow management application such as a pharmacist during dosage review. The data cube class definition related to a scan error may include data dimensions related to the dosage in which a prevented error occurred during dosage preparation, dosage category, dosage identifier, scanned barcode, scanned official product information, scanned product log information, technician information, and workstation information. The data cube class definition related to a detected error may include detected error data occurring at the pharmacist's confirmation station. The data dimensions included within the detected error data cube class definition may include the reason for re-preparing the dosage, pharmacist information, technician information, workstation information, preparation location, nursing unit related to the dosage, administration route of the dosage, whether the dosage is a dangerous dosage, type of dangerous dosage, whether the dosage is a TPN order, and dosage description. The data cube class definition related to the bypass reason may include information related to the dosage related to the bypass printing operation, whereby when the dosage order is received by the pharmacy workflow management application, the label printer bypasses it to print the dosage order in the conventional format. Thus, the data dimensions of the bypass reason data cube class definition may include the indication that the dosage was bypassed, order input date and time, drug information corresponding to the dosage order, information related to the source of the data order, and the like.The data cube class definition for dosage order corrections may include data dimensions that include what dosage corrections were made, including updates to administration date / time, dosage interruptions, changes in dosage priority, movement to or from a held status of the dosage, expiration date / time of the dosage by using stock items with an earlier expiration date, whether the system automatically or the user intentionally adjusted the dosage, the name of the corrector, and the reason a correction was needed (e.g., if the site is configured to enter a reason for the correction). The data cube class definition for dosage alerts may include data dimensions corresponding to whether the dosage received an alert during the preparation process and other dosage identification information that can enable determination of trends related to dosage alerts. Other data cube class definitions may include data dimensions related to received alerts for some other parts of the data stored by the dosage order, patient, drug, or pharmacy workflow management application (e.g., from an alert provider within or external to the pharmacy workflow management system).

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

[0070] The product category and treatment category of the data cube class definition may include data cube class definitions related to treatment summaries and drug combinations. Thus, the data cube class definition related to the treatment summary may include data dimensions corresponding to the ability to examine examples of drug therapy with respect to, for example, customer identifiers, source identifiers, dosage entry dates, drug names of dosages, dosage descriptions, and average duration (e.g., number of days, number of dosages, or total dosage amount) including treatment IDs. The drug combination data cube class definition may include a "cross-tab" indicating the frequency of drug combinations when given together. The data dimensions of this data cube class definition may include customer identifiers, source identifiers, dosage entry dates, drug names related to dosages, dosage amounts, dosage units, and dosage identifiers.

[0071] Multiple data cube class definitions can be related to compliance tracking. Examples can include data cube class definitions related to planned task history and weight measurements. The planned task history data cube class definition may include data dimensions that can enable the completion of compliance tracking for planned tasks with respect to a workstation. In this regard, the data dimensions of the data cube may include workstation tasks, failed task dose counts (e.g., the number of defective doses due to a clean task not being completed on time), completed task information (e.g., including user, time, workstation, whether the task has exceeded the deadline, and the deadline exceeded time), how many doses the user has prepared at the deadline-exceeded workstation, frequency type, frequency value, previous completion date / time, previous deadline date / time, and next deadline date / time. The weight measurement data cube class definition may include data corresponding to the weight measurement value recording dose preparation workstation. Further, based on the data cube class definition related to compliance tracking, doses can be filtered and / or searched based on multiple different data dimensions such as, for example, dose type, dose preparation date, technician, location, or other appropriate dimensions. Further, a dynamic report generated based on compliance tracking can enable a user to drill down through various dimension levels. At a given level, the user can select and view individual dose order records including a given data set (e.g., a chart cell or graph portion can correspond to a given number of doses, which can be explicitly listed as a list of specific dose order records referenced by the graph portion of the chart cell based on the user's selection). That is, the report enables the user to select or define various parameters and access a list of doses that meet the criteria established by the user using the selection of various parameters. The compliance tracking data cube may include a link that enables a user to search for a dose order log corresponding to a given dose order included in a list of specific dose order records.The dosage order log may contain any or all information regarding the selected dosage order (e.g., data regarding the dosage order record other than the data dimensions of the data cube used to filter or search for the dosage order itself). That is, the dosage order record may contain any or all information regarding the dosage order log, even if the dosage order information does not have the dimensions included in the data cube used to obtain a link to access the dosage order log for the dosage order record. In an application, the dosage order log linked to the compliance tracking data cube can correspond to a dosage order log having a specific format and / or data content specified by an agency such as a government regulatory agency used in determining regulatory compliance.

[0072] In addition, 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, central user navigation-related data, and audit logs. The data cube class definition for web session information may include, for example, the user's IP address, login date / time, logout date / time, browser name, browser version, browser extension installation version, session length, breakdown display between site configuration time and dosage preparation function time, average response time from the server for web service requests, and average response time for web page requests, including data dimensions corresponding to information related to web-based user sessions. The data cube class definition related to the workstation session may include data dimensions related to the workstation's login date / time, logout date / time, workstation software version, workstation name, workstation location, username accessing the workstation, and date / time of the last activity. The data cube class definition related to the central user session may include data dimensions corresponding to the central session log, session total time, and browser type / version. The cube 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 full snapshots of the audit log to identify which fields have been changed.

[0073] Other data cube class definitions that can utilize various data dimensions present in the dosage order information can be provided without limitation. Furthermore, the source data for the data cube class definition can be expanded beyond the dosage order data. For example, additional data sources (such as those located in a hospital information system, pharmacy information system, research institute, surgical data repository, prescription records, national medical database, etc.) can be accessible by a data analysis tool. In this regard, a data cube class definition that references the said data source can be provided. In addition, a data cube class definition can be provided for use in constructing a data cube that references multiple data sources (such as including dosage order data and the other data sources mentioned above like a hospital information system, pharmacy information system, research institute, surgical data repository, and national medical database). In any case, the aforementioned data cube class definition can be used to construct the corresponding data cube. In this regard, one or more reports can be generated that reference the data cube to present data to the user. The reports can take the form of pivot tables, dashboards, charts, graphs, or other report structures. The reports can be filterable based on various different data dimensions (such as, for example, dosage order type, date, dosage status, technician, pharmacist, or other data dimensions included in the data cube and defined in relation to the report) (e.g., it can be modifiable by a user with appropriate roles and responsibilities). Furthermore, the reports include drill-downs based on the above dimension levels and can provide more detailed data based on a subset of the given dimension data. In this regard, the user may be able to use the reports to identify trends, anomalies, patterns, or other information from the data presented in the dynamic reports generated based on the data cube.

[0074] Although the present invention has been illustrated and described in detail in the drawings and the foregoing description, such illustration and description should be considered as exemplary and not restrictive of the features. For example, the above specific embodiments may be combined with other described embodiments and / or may be configured in other ways (e.g., process elements may be executed in other orders). Therefore, it should be understood that only the preferred embodiments and their modifications have been shown and described, and it is desirable that all modifications and changes included in the spirit of the present invention be protected.< / userid> < / customerid> < / username> < / userid> < / customerid>

Claims

1. A system for providing a user with selective access to a data analysis tool for processing a multi-dimensional data set corresponding to the dosage order record in providing the user with data analysis regarding a subset of dosage order records of a multi-dimensional data set, a central server operably communicating with a plurality of local servers, each local server being located at a respective corresponding facility that prepares a dosage corresponding to a dosage order for administration to a patient, the central server receiving information regarding the dosage order record corresponding to the dosage order from the local server, a database in the central server storing a data structure comprising a multi-dimensional data set including a plurality of dosage order records received from the plurality of local servers, each of the plurality of dosage order records of the multi-dimensional data set including at least one display data regarding the facility that is the source of the received dosage order record, a local server interface configured to operably communicate with a user workstation for receiving user information from a user at one of the plurality of facilities, wherein the user information includes one or more identifiers corresponding to a predetermined facility where the user is accessing the data analysis tool, a data analysis interface that, by operably communicating with the data analysis tool, provides the data analysis tool with access to the multi-dimensional data set stored in the database and creates a dynamically generated report regarding a subset of the multi-dimensional data set corresponding to the predetermined facility where the user is accessing the data analysis tool based on the user information received from the local server interface, wherein the user information corresponding to the predetermined facility where the user is accessing the data analysis tool restricts access to data other than the subset of the multi-dimensional data set, and a user interface for presenting the dynamically generated report regarding the subset of the multi-dimensional data set corresponding to the predetermined facility where the user is accessing the data analysis tool to the user at the user workstation A system comprising.

2. The system according to claim 1, wherein the data analysis tool uses a plurality of data cube class definitions applicable to the multi-dimensional data set to create the dynamically generated report.

3. The system according to claim 2, wherein the plurality of data cube class definitions includes a basic cube class definition to which all other of the plurality of data cube class definitions are subordinate.

4. The system according to claim 3, wherein the basic cube class definition includes at least one data dimension related to the at least one display data for the predetermined facility that is the source of the dosage order record.

5. The system according to claim 4, wherein the data analysis tool is further operative to perform at least one data conversion operation on a subset of the multi-dimensional data set, wherein the at least one data conversion operation is defined by the basic cube class definition.

6. The system according to claim 5, wherein the at least one data conversion operation includes automatically rewriting a first data field of each predetermined dosage order record in the subset with a respective second data field of the dosage order records of the subset.

7. The system according to claim 6, wherein the at least one data conversion operation is applied only to a predetermined type of the dosage order records.

8. The system according to claim 7, wherein the predetermined type of the dosage order records includes total parenteral nutrition (TPN) dosages, the first data field comprises a dosage description field, and the second data field comprises a drug name field for a predetermined dosage.

9. The system according to claim 5, wherein the central server calls other data cube class definitions subordinate from the basic cube class definition for application to a subset of the multi-dimensional data set corresponding to the predetermined facility, and is further operative to create the dynamically generated report regarding the subset of the multi-dimensional data set.

10. The system according to claim 9, wherein the plurality of data cube class definitions includes a parameter indicating whether a data cube constructed using the data cube class definition includes protected health information (PHI).

11. The system according to claim 10, wherein the parameter is dynamically generated based on at least one dimension of the data cube class definition.

12. The user workstation operates to receive login information from the user accessing the data analysis tool and start a user session, where the user workstation communicates with the central server to authenticate the user to the central server based on the login information received at the user workstation, and the central server operates to add session variables related to the user session based on the authenticated user login information, and the session variables include the user information including one or more identifiers corresponding to a predetermined facility where the user is accessing the data analysis tool. The system according to claim 1.

13. The data analysis tool further comprises an encryption service that operates to receive a token from a user attempting to access the central server, where the token is at least partially based on the session variables added by the central server, and the encryption service operates to compare the token with tokens available at the central server to determine whether the user should be permitted access to the data analysis tool. The system according to claim 12.

14. When the token matches one of the available tokens, issue the token to the user and remove the corresponding available token from the central server. The system according to claim 13.

15. The session variables include a role definition of the user generated at least partially based on the login information. The system according to claim 12.

16. The role definition includes a display related to 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. The system according to claim 15.

17. The system according to claim 1, further comprising a logging module that operates to log (record) user activities in relation to the use of the data analysis tool by the user.

18. The system according to claim 17, wherein the logging includes recording information regarding the user and the use of the data analysis tool by the user.

19. The system according to claim 18, wherein the logging includes recording the identification of the dynamically generated report presented to the user.

20. The system according to claim 19, wherein the logging includes recording whether the dynamically generated report presented to the user contains protected health information (PHI).

21. The multi-dimensional dataset comprises data regarding the identification of dosages corresponding to the plurality of dosage order records, data regarding the preparation process of the dosages, data regarding the timing of the dosages, data regarding errors occurring during the preparation of the dosages, data regarding the disposal of products, data regarding drug use, data regarding administered drug therapies, data regarding drug interactions, and data regarding data corresponding to alerts in a pharmacy workflow management application. The system according to claim 1.

Images