JP2021047930A - 用量調製データ分析 - Google Patents

Abstract

【課題】用量命令記録に関する多次元データに関連して使用するデータ分析ツールの提供。【解決手段】用量命令記録に関するデータ分析の生成のための用量命令記録を含む集約された多次元データセットへの選択的且つ安全なアクセスを提供する。集約されたデータは、複数の関連しない施設に対応することができる。このように、所定の施設のユーザがデータ分析ツールにアクセスしようと試みると、ツールにアクセスしているユーザの施設に関連して識別することができる。次に、他の全てのデータ分析データキューブが継承するデータキューブクラス定義を使用して、ユーザ識別に関連して使用するデータを制限してデータ分析出力をユーザが閲覧することを認証されたソースデータへ生成する。出力には、例えば、レポート、ダッシュボード、テーブルなどが含まれてよい。【選択図】図１

Description

関連出願
本願は、２０１４年１２月５日に出願された「ＤＯＳＥ ＰＲＥＰＡＲＡＴＩＯＮ ＤＡＴＡ ＡＮＡＬＹＴＩＣＳ」というタイトルの米国仮特許出願第６２／０８８，３５８号の優先権を主張するものであり、その内容は、全て記載されるかのように参照により本明細書において援用される。

本発明は、概して医療データ管理の分野に関し、特に、例えばある施設に基づいて、当該施設に関連するツール及びデータのユーザに対応するデータの多次元レポジトリへの特定の制限されたアクセスが提供されるように、用量命令記録情報に使用するためのデータ分析を促進することに関する。

病院などの医療施設は、患者への投与のための用量命令記録を調製する要求に関連して、用量命令情報を薬局に提供することがよくある。薬局で受信された用量命令を処理する従来のアプローチには、例えば、調製される各用量命令のための物理的ラベルを印刷することが含まれる。次に、当該用量命令に関連する薬局における活動は、ワークフロー管理のために物理的ラベルを使用することを前提とする。当該物理的ラベルを紛失、誤配置又は混乱しやすいことに加えて、薬局スタッフが物理的ラベルによって表示される用量命令を整理、管理又は伝達する能力も限られていた。

薬局での用量命令の調製に関連する従来のアプローチの限界に加えて、用量命令調製後の薬事活動を定量化し、追跡し、その他再検討する能力も限られていた。例えば、調製完了時に用量命令に添付される物理的ラベルの使用には、薬事業務の退屈な手作業での記録を行わずに特定の用量命令に関して薬局で実施された活動を記録又は監査する手段が残されていない。薬事業務の手作業による記録は時間がかかり、誤記が発生しやすく、また信頼性が低いため、薬事活動の定量化、追跡及び再検討のための実行可能な選択肢を提示していない。次に、薬局の活動に関する貴重な情報は、薬局又は病院の管理者には可視化されていなかった。

薬局などによって調製される又は調製されてきた用量命令の調製、追跡、構成及び文書化を支援するために、薬局ワークフロー管理アプリケーションが開発されている。例えば、２０１３年９月１０日に出願された「ＭＡＮＡＧＥＭＥＮＴ，ＲＥＰＯＲＴＩＮＧ ＡＮＤ ＢＥＮＣＨＭＡＲＫＩＮＧ ＯＦ ＭＥＤＩＣＡＴＩＯＮ ＰＲＥＰＡＲＡＴＩＯＮ」というタイトルの共有米国特許出願公開第１４／０２２，４１５号があり、参照によりその全体が本明細書に援用される。これに関して、受信された及び／又は追加された用量命令情報及び／又は用量命令メタデータを含む用量命令記録を、患者への投与のための用量命令を調製する施設で生成及び記録することができる。さらに、当該用量命令記録は、複数の施設と動作可能に通信する中央サーバに格納することができる。これに関して、複数の施設からの用量命令記録は、中央サーバに集合的に格納することができる（例えば、データのバックアップ等に関連する目的のために）。

上記を考慮すると、中央的な場所（例えば、中央サーバ）に格納される複数の施設からの用量命令情報を有利に使用して、一つ以上の施設に関連する格納されたデータに関してレポート、メトリクスなどを提供することができることが認識されている。具体的には、中央サーバと動作可能に通信するデータ分析ツールを設けることができ、このデータ分析ツールは、中央サーバに格納されたデータにアクセスしてデータ分析（例えば、動的レポートなど）を提供することができる。データ分析ツールは中央サーバのデータにアクセスできるので、個々の施設がデータ分析ツールへのインターフェースを維持する必要なしに１つ以上の施設に関連して当該分析を提供することができる。有利には、しかしながら、中央サーバのデータは複数の異なる施設からのデータを含むことができるので、当該レポートへの選択的なアクセスを提供することにより、中央サーバのデータのアクセス時に施設のそれぞれから個人に対するセキュリティ及び制限されたアクセスを維持しながら、データ分析ツールの集中的な適用が可能であることも認識されている。

このように、本発明は、用量命令記録に関する多次元データに関連して使用するデータ分析ツールを提供する能力を付与する医療データ管理について説明する。具体的には、本発明は、多次元データセットへの選択的アクセスを可能にすることを企図する。例えば、複数の施設からの用量命令記録を、多次元データセットとして集合的に格納することができる。基本データキューブクラス定義を生成することができ、これは、ツールにアクセスするユーザの識別を使用してユーザがアクセス権を有する記録のサブセットを決定する。これに関して、基本キューブクラス定義は、動的に生成されるレポートにおいてユーザに提示するためのデータ記録のフィルタリングを可能にするデータ次元を有することができる。これに関して、追加のデータキューブクラス定義は、基本データキューブクラス定義から継承することができ、その結果、ユーザはアクセスを認証されたデータに対応するレポートデータを検索することだけができるようになる。

この点に関して、第１の態様は、多次元データセットの用量命令記録のサブセットに関するデータ分析をユーザに提供するのに使用する用量命令記録に対応する多次元データセットを処理するためのデータ分析ツールへの選択的なアクセスをユーザに提供する方法を含む。本方法は、複数の用量命令記録に対応する情報を備える多次元データセットを格納することを含む。多次元データセットの複数の用量命令記録は、用量命令記録に対応する施設の少なくとも１つの表示を含む。多次元データセットは、複数の施設に対応する用量命令記録を含む。本方法は、複数の施設の１つのユーザからユーザ情報を受信することを更に含む。ユーザ情報はユーザがデータ分析ツールにアクセスしている所定の施設を表示する情報である。本方法は、データ分析ツールが多次元データセットにアクセスして、ユーザがデータ分析ツールにアクセスしている所定の施設に対応する多次元データセットのサブセットに関する動的に生成されるレポートを生成することも含む。加えて、本方法は、ユーザがデータ分析ツールにアクセスしている所定の施設に対応する多次元データセットのサブセットに関する動的に生成されるレポートをユーザにユーザインターフェースで提示することを含む。

第１の態様に、複数の特徴の改良及び追加の特徴が適用可能である。これらの特徴の改良及び追加の特徴は、個別に又は任意の組み合わせで使用できる。このように、説明される以下の特徴のそれぞれは、第１の態様の他の特徴又は特徴の組み合わせと共に使用することができるが、必須ではない。

例えば、ある実施形態では、データ分析ツールは、動的に生成されるレポートを生成するために多次元データセットに適用可能な複数のデータキューブクラス定義を備えることができる。複数のデータキューブクラス定義は、複数のデータキューブクラス定義の他の全てが従属する基本キューブクラス定義を備えることができる。基本キューブクラス定義は、用量命令記録に対応する施設の少なくとも１つの表示に関連する少なくとも１つのデータ次元を含むことができる。次に、本方法は、ユーザがデータ分析ツールにアクセスしている所定の施設を表示するユーザ情報に基づいて、多次元データセットに基本キューブクラス定義を適用し、ユーザがデータ分析ツールにアクセスしている所定の施設に対応する多次元データセットのサブセットにユーザがアクセス可能なデータを制限するデータキューブを当該適用に基づいて構築することを含むことができる。

ある実施形態では、構築することは、多次元データセットのサブセットにおいて少なくとも１つのデータ変換操作を実行することを更に含むことができ、少なくとも１つのデータ変換操作は、基本キューブクラス定義で定義される。少なくとも１つのデータ変換は、サブセットにおける各所定の用量命令記録の第１のデータフィールドを、サブセットの用量命令記録のそれぞれの第２のデータフィールドで自動的に書き換えることを含むことができる。少なくとも１つのデータ変換を、用量命令記録の所定のタイプのみに適用することができる。用量命令記録のタイプは、完全腸管外栄養（ＴＰＮ）用量であることができ、第１のデータフィールドは用量説明フィールドであることができ、第２のフィールドは所定の用量の薬品名フィールドであることができる。

ある実施形態では、本方法は、ユーザがデータ分析ツールにアクセスしている所定の施設に対応する多次元データセットのサブセットに適用するために基本キューブクラス定義から従属する他のデータキューブクラス定義を呼び出し、多次元データセットのサブセットに関する動的に生成されるレポートを生成することを更に含むことができる。ある実施形態では、複数のデータキューブクラス定義は、データキューブクラス定義を使用して構築されたデータキューブが保護対象保健情報（ＰＨＩ）を含むかどうかを示すパラメータを含むことができる。パラメータは、データキューブクラス定義の少なくともの１つの次元に基づいて動的に生成できる。

ある実施形態では、受信することは、ユーザがデータ分析ツールにアクセスしている所定の施設で常駐するローカルサーバでログイン情報を受信してユーザセッションを開始し、ローカルサーバで受信されたログイン情報に基づいてユーザを中央サーバに対して認証すること、及び認証されたユーザログイン情報に基づいてユーザセッションに関連するセッション変数を追加することを含むことができる。セッション変数は、ユーザがデータ分析ツールにアクセスしている所定の施設を表示するユーザ情報を含むことができる。これに関して、本方法は、少なくともいくつかの適用において、セッション変数に少なくとも部分的に基づいてトークンをデータ分析ツールに渡すことを含むことができる委譲された認証処理を含むことができる。トークンを中央サーバで利用可能なトークンと比較して、ユーザがデータ分析ツールへのアクセスを許可されるべきかどうかを決定する。従って、トークンが利用可能なトークンの１つと一致すると、トークンをユーザに発行することができ、対応する利用可能なトークンを中央サーバから除去する。いくつかの適用では、セッション変数は、ユーザが受信するログイン情報に少なくとも部分的に基づいて生成されるユーザのためのロール定義を含む。ロール定義には、レポートの閲覧、レポートの編集、キューブクラス定義の閲覧、キューブクラス定義の編集、ピボットテーブルの閲覧、ピボットテーブルの編集、ダッシュボードの閲覧及びダッシュボードの編集に関連するユーザの能力に関する表示が含まれていてよい。

本方法は、ユーザによるデータ分析ツールの使用に関連してユーザアクティビティをロギング（記録）することを更に含む。ロギングすることは、ユーザとユーザによるデータ分析ツールの使用とに関する情報を記録することを含むことができる。ロギングすることは、ユーザに提示される動的に生成されたレポートの識別を記録することを含むことができる。ロギングすることは、ユーザに提示される動的に生成されたレポートが保護対象保健情報（ＰＨＩ）を含んでいたかどうかを記録することを含むことができる。多次元データセットは、用量の識別、用量の調製工程に関するデータ、用量のタイミングに関するデータ、用量調製中に生じたエラーに関するデータ、製品の廃棄に関するデータ、薬品使用に関するデータ、投与された薬物療法に関するデータ、及び薬物相互作用に関するデータを含むことができる。

第２の側面は、多次元データセットの用量命令記録のサブセットに関するデータ分析のための用量命令記録に対応する多次元データセットを処理するためのデータ分析ツールを実装するためのシステムを含む。本システムは、複数のローカルサーバと動作可能に通信する中央サーバを含み、各ローカルサーバは患者に投与するための用量命令に対応する用量を調製するそれぞれの対応施設に配置されている。中央サーバは、ローカルサーバからの用量命令に対応する用量命令記録に関する情報を受信する。本システムは、複数のローカルサーバから受信する複数の用量命令記録を含む多次元データセットを備えるデータ構造を格納する中央サーバにあるデータベースも含む。多次元データセットの複数の用量命令記録のそれぞれは、用量命令記録の受信元の施設の少なくとも１つの表示を含む。本システムは、複数の施設の１つのユーザからのユーザ情報を複数のローカルサーバの少なくとも１つから受信するための複数のローカルサーバと動作可能に通信するローカルサーバインタフェースも含むことができる。ユーザ情報はユーザがデータ分析ツールにアクセスしている所定の施設を表示する情報である。本システムはまた、データ分析ツールとの動作可能な通信を促進するデータ分析インターフェースを含むことができる。データ分析インターフェースは、データベースに格納される多次元データセットへのデータ分析ツールアクセスを提供し、ローカルサーバインタフェースから受信するユーザ情報に基づいてユーザがデータ分析ツールにアクセスしている所定の施設に対応する多次元データセットのサブセットに関する動的に生成されるレポートを生成する。本システムはまた、ユーザがデータ分析ツールにアクセスしている所定の施設に対応する多次元データセットのサブセットに関する動的に生成されるレポートをユーザインターフェースでユーザに提示するユーザインターフェースを含むことができる。

第２の態様に、複数の特徴の改良及び追加の特徴が適用可能である。これらの特徴の改良及び追加の特徴は、個別に又は任意の組み合わせで使用できる。このように、第１の他態様に関連して上で説明される特徴のそれぞれは、第２の態様の他の特徴又は特徴の組み合わせと共に使用することができるが、必須ではない。

第３の側面は、多次元データセットの用量命令記録のサブセットに関するデータ分析をユーザに提供するのに使用する用量命令記録に対応する多次元データセットを処理するためのデータ分析ツールへの選択的なアクセスをユーザに提供するためのシステムを含む。本システムは、複数のローカルサーバと動作可能に通信する中央サーバを含み、各ローカルサーバは患者に投与するための用量命令に対応する用量を調製するそれぞれの対応施設に配置されている。中央サーバは、ローカルサーバから用量命令に対応する用量命令記録に関する情報を受信する。本システムはまた、複数のローカルサーバから受信する複数の用量命令記録を含む多次元データセットを備えるデータ構造を格納する中央サーバにあるデータベースも含む。多次元データセットの複数の用量命令記録のそれぞれは、用量命令記録の受信元の施設の少なくとも１つの表示を含む。本システムはまた、複数の施設のうちの１つのユーザからのユーザ情報を複数のローカルサーバの少なくとも１つから受信するための複数のローカルサーバと動作可能に通信するローカルサーバインタフェースを含む。ユーザ情報はユーザがデータ分析ツールにアクセスしている所定の施設を表示する情報である。本システムはまた、データベースに格納される多次元データセットにアクセスするためにデータベースと動作可能に通信し、ローカルサーバインタフェースから受信するユーザ情報に基づいてユーザがデータ分析ツールにアクセスする所定の施設に対応する多次元データセットのサブセットに関する動的に生成されるレポートを生成するデータ分析ツールも含む。本システムはまた、ユーザがデータ分析ツールにアクセスしている所定の施設に対応する多次元データセットのサブセットに関する動的に生成されるレポートをユーザインターフェースでユーザに提示するユーザインターフェースも含む。

第３の態様に、複数の特徴の改良及び追加の特徴が適用可能である。これらの特徴の改良及び追加の特徴は、個別に又は任意の組み合わせで使用できる。このように、第１の側面に関連して上で説明される特徴のそれぞれは、第３の態様の他の特徴又は特徴の組み合わせと共に使用することができるが、必須ではない。

図１は、複数の施設からの集約された多次元データセットに関連する選択的で安全なデータ分析システムの一実施形態の概略図である。 図２は、図１のシステムに関する例示的な施設に関連するデータフローの一実施形態の概略図である。 図３は、選択的で安全なデータ分析システムの動作の一実施形態の概略図である。 図４は、データ分析システムにおいて使用する委譲されたユーザ認証の一実施形態を示すフローチャートである。 図５は、薬局ワークフロー管理ログイン画面の一実施形態のスクリーンショットである。 図６は、薬局ワークフロー管理ホーム画面の一実施形態のスクリーンショットである。 図７は、薬局の中央レポート画面の一実施形態のスクリーンショットである。 図８は、データ分析レポートリスト画面の一実施形態のスクリーンショットである。 図９は、データ分析レポート表示画面の一実施形態のスクリーンショットである。 図１０は、データ分析ツール構成セットアップの一実施形態を示す。 図１１は、データ分析ツールに関連して使用することのできるロギングスキーマの一実施形態を示す。

以下の説明は、本発明を本明細書に開示した形態に限定するものではない。結果として、関連技術の以下の教示、技術及び知識に伴う変更及び修正は、本発明の範囲内である。本明細書に記載される実施形態は、本発明を実施する際の知見となるモードを説明し、当業者が本発明を当該実施形態又は他の実施形態で使用し且つ本発明の特定の適用又は使用によって必要とされる様々な修正と共に使用できることが更に意図される。

図１を参照すると、本明細書で説明されるような分散環境における選択的で安全なデータ分析を容易にするシステム１０が示される。システム１０は、中央サーバ１２を含むことができる。中央サーバ１２は、複数の施設１４と動作可能に通信することができる。例えば、図１に示すように、中央サーバ１２は、第１の施設１４Ａ、第２の施設１４Ｂ及び第３の施設１４Ｃと動作可能に通信することができる。ただし、３つの施設１４Ａ、１４Ｂ、１４Ｃは例示目的のために図１に示されているが、それより少ない又は多い施設１４を中央サーバ１２と動作可能に通信された状態で設けることができ、図１に示す３つの施設１４Ａ〜１４Ｃは単に例示目的であるものとすることが理解されよう。

従って、少なくとも１つの実施形態では、施設１４は、患者への投与のために投薬用量を調製することができる、関連のない個別の医療施設１４を構成することができる。中央サーバ１２は、施設１４の実体のいずれかとは分離されていてもよい他の個別の関連のない第三者によってホストされていてもよい。例えば、中央サーバ１２は、薬局ワークフロー管理アプリケーションを容易にするために施設１４が実行する１つ以上のクライアントアプリケーションを提供するアプリケーションプロバイダによってホスト及び／又は実行されてもよい。具体的には、中央サーバ１２は、薬局ワークフロー管理アプリケーションを各施設１４に提供するアプリケーションプロバイダによって実行又はホストされてもよい。

このように、施設１４Ａ、１４Ｂ及び１４Ｃは、施設１４Ａ、１４Ｂ及び１４Ｃが施設１４Ａ、１４Ｂ及び１４Ｃのそれぞれで調製される用量命令を受信、処理、構成、調製、追跡又はその他管理することができる薬局ワークフロー管理アプリケーションを実行することができる。これに関して、各施設１４は、施設１４のそれぞれで処理された用量命令に関連する用量命令情報を生成することができる。次に、施設１４は、中央サーバ１２と動作可能に通信していてもよく、中央サーバ１２に用量命令データを提供することができる。

これに関して、用量命令データには、処理される用量命令に関する情報の１つ以上のクラスが含まれていてよい。例えば、用量命令データには、薬局で受信される用量命令に対応する情報（例えば、医師命令入力（ＰＯＥ）システムによって入力される情報、薬局情報システム（ＰｈＩＳ）が受信する情報などを含む）が含まれていてよい。用量命令データにはまた、用量命令の調製に関連して付随及び／又は生成されるデータが含まれていてよい。この情報には、用量命令を調製するために使用される製品（例えば、薬品、薬局製品又はハードウェア）に関するデータが含まれていてよい。このように、情報には、国家薬物コード（ＮＤＣ）、ロット番号及び有効期限など用量を調製するために使用される１つ以上の薬物（又はすべての薬物）に関する情報が含まれていてよい。情報にはまた、用量に関して行動する人員の識別に関連する情報、用量に関連する時間イベント、用量調製及び／又は検証に関連する画像、用量処理中に検出又は発生したエラー、薬剤師による用量のレビューに関連する情報、薬局及び／又は投与環境における用量に関する追跡情報など調製メタデータも含まれていてよい。要するに、用量命令データは、記録され、生成され、追加され又はその他用量命令と関連付けられる、用量命令又は用量命令の調製に関する任意の情報を含むことができる。

加えて、データ分析サーバ１６は、中央サーバ１２と動作可能に通信することができる。以下により詳細に説明するように、データ分析サーバ１６は、中央サーバ１２のデータに適用することのできるデータ分析ツールを備えることができ、例えば、データ分析ツールが中央サーバ１２で適用されるデータに関してデータ分析に使用する動的に生成されるレポートを生成することができる。データ分析ツールには、データ分析に使用する動的レポートの生成を容易にするためにデータに関連して実行されるデータ構成及びトランザクションを定義するデータキューブクラス定義が含まれていてよい。当該データキューブクラス定義については、以下でさらに詳細に説明する。いずれの点でも、データキューブクラス定義を中央サーバ１２のデータに適用して、適用時にデータキューブクラス定義がデータ分析ツールによって提供されるデータに関連するデータ分析を容易にすることができると認められ得る。

このように、それぞれの施設１４からのユーザは、分析サーバ１６が提供するデータ分析ツールにアクセスして中央サーバ１２に格納されたデータに関連して使用するデータ分析ツールを呼び出すよう操作可能である。上で概説したように、中央サーバ１２と動作可能に通信するデータ分析サーバ１６を設けることにより、システム１０のインターフェースの複雑さを単純化することができる一方で（例えば、データ分析サーバ接続を各施設に直接設けることとは対照的に）、中央サーバ１２とのインターフェースによって、中央サーバ１２に格納されたデータに選択的で安全なアクセスを提供することの必要性が生じる場合がある。具体的には、中央サーバ１２は、複数の施設１４からのデータを格納することができるので、所定の施設（例えば、第１の施設１４Ａ）からのユーザに、他の施設（例えば、第２の施設１４Ｂ又は第３の設備１４Ｃ）からのデータへのアクセスを提供すべきではないという場合がある。すなわち、選択的なアクセスをユーザに提供し、その結果、所定の施設のユーザには、ユーザがデータ分析ツールにアクセスしている施設に関するデータに関連したデータ分析へのアクセスを提供することだけができる。これに関して、以下により詳細に説明するように、システム１０はデータ分析ツールにアクセスする施設１４に特化したデータの一部に関連したデータ分析ツールに選択的で安全なアクセスを提供することができる。

以下の開示では、ユーザがデータ分析ツールにアクセスしている施設を決定することにより施設ごとに施設における選択的なアクセスを提供することを述べているが、所定の施設からツールにアクセスするユーザは組織ユーザであってもよいことが理解できる。すなわち、複数の施設が一つの組織を構成することができる。このように、組織を構成する施設のうちの所定の施設からツールにアクセスするユーザは、組織を構成する複数の施設からのデータにアクセスするのに十分な資格を有することができる。従って、本明細書では、データのアクセスに関して施設ごとの判定として潜在的に説明するが、ツールにアクセスするユーザがデータを閲覧しツールを使用するのに十分な資格を有している限り、中央サーバのデータをデータ分析ツールを使用して分析できるようにシステムを実行することができる。

図２は、システム１０の部分間の情報の流れを示すシステム１０の概略図を更に示す。図２において、施設１４のインスタンスのそれぞれにユーザワークステーション１８とローカルサーバ２２とを設けることができる。施設１４の単一のインスタンスを図２に示しているが、図１の開示に関連して、ユーザワークステーション１８とローカルサーバとをそれぞれ有する複数の施設１４は、図２に示す所定の施設１４に関連して説明するのと同様の情報フローを受けることができることが理解できる。更に、単一のユーザーワークステーション１８はローカルサーバ２０と動作可能に通信するように描かれているが、複数のユーザワークステーション１８をローカルサーバ２０と動作可能に通信するよう設けてもよく、本明細書に提供される説明に全体的に従うことができることを理解することができる。ユーザワークステーション１８は、ローカルサーバ２０と動作可能に通信することができ、ユーザワークステーション１８とローカルサーバ２０との間で用量命令データを交換することができる。このデータ交換には、ローカル用量命令データレポジトリ２２（例えば、ローカルサーバ２０でデータベースなどに格納される）とユーザワークステーション１８との間の用量命令情報の交換が含まれる。これにより、用量の調製、用量命令情報の生成又はキャプチャ、薬剤師による調製された用量命令のレビュー又は薬局ワークフローマネージャが提供する他の活動において使用するための用量命令情報を、ユーザワークステーション１８に提供することが容易にできる。

ローカル用量命令データ２２を、ローカルサーバ２０から中央サーバ１２へと提供することができる。これに関して、中央サーバ１２は、集約されたローカル用量命令データ２４を格納することができる。例えば、集約されたローカル用量命令データ２４には、図１に示す複数の施設から受信する用量命令データが含まれていてよい。理解できるように、集約されたローカル用量命令データ２４における用量命令データには、受信するデータ２４の元の施設（又は組織）に関する表示が含まれていてよい。次に、データ分析サーバ１６には、データキューブクラス定義２６が含まれていてよい。以下により詳細に説明するように、データキューブクラス定義２６には、値、尺度、計算された尺度、インデックス又は中央サーバ１２でのデータ上で実施される他のデータ操作を定義して、データ分析サーバ１６が提供するデータ分析ツールに関連してデータ分析を容易にすることができる。これに関して、データキューブクラス定義２６をデータ又はデータのサブセットに関連して呼び出し、中央サーバ１２に配置される集約されたローカル用量命令データリポジトリ２４に提供することができる。

上述したように、中央サーバ１２での集約されたデータに関連するデータ分析ツールを提供することは、中央サーバ１２に関連する単一のインターフェースを維持することができるという付帯的な効率をもたらし、その結果、各所定の施設１４とデータ分析サーバ１６との間のインターフェースを提供又は維持することを要しないことが認識されている。このように、例えば、新たなデータキューブクラス定義２６の開発を、データキューブのすべてのユーザに各施設１４が個別に使用する当該キューブを特別に開発する必要なく提供することができる。しかしながら、集約されたローカル用量命令データリポジトリ２４上でデータ分析を実施することに関連して、施設のそれぞれからのユーザが、ユーザが閲覧することに対応する資格を有する中央サーバ１２のデータのみにアクセスすることを可能にする機構を提供することが必要な場合がある。そうでなければ、施設１４のそれぞれ個別に関するデータ完全性が失われる場合がある。

従って、本明細書で企図されるように、ユーザ認証プロセスが設けられ、それにより、ユーザはユーザ情報を提供することが要求され、次に当該情報を使用してユーザがデータ分析ツールにアクセスしている施設を決定することができる。ユーザ識別情報に基づいて、ユーザがアクセスしているデータを決定することにより、ユーザに対応する施設（又は組織）に対応するデータを適切に制限することができる。従って、図３は、データ分析サーバ１６が提供するデータ分析ツールへのアクセスに関連してユーザを認証することを可能したシステム１０に関して示されるプロセスフロー１００の概略図を示す。ユーザ認証はまたユーザ識別情報を提供し、当該ユーザ識別情報を使用してユーザがデータ分析ツールに関連して使用するために中央サーバ１２でアクセスしているデータが何かを決定することができる。これに関して、プロセスフロー１００を使用して、データ分析サーバ１６が提供するデータ分析ツールに関連して中央サーバ１２でユーザがアクセスしているデータを適切に限定することができる。ユーザ認証の一部は、データ分析サーバ１６から離れたローカルサーバ２２及び／又は中央サーバ１２で実施することができるので、認証プロセスは、委譲された認証プロセス（以下に詳細に説明する）と呼ぶことができる。このように、従来のデータ分析ツールでは、単一のデータソース上での操作のために直接そこにアクセスする必要がある場合がある。しかしながら、現在説明している概念では、データソースは、実際に、データ分析サーバから遠隔に格納された複数の集約データソースを備えることができる。このように、委譲された認証プロセスによって、適切なデータが適切なユーザに対して制限されたアクセスを提供するような方法で遠隔データへのアクセスを可能にすることができる。

最初に、図３に関して、ユーザワークステーション１８に関連する様々なユーザインターフェースの状態を、ユーザワークステーション１８に関連して参照する。従って、当業者であれば理解できるように、ユーザインターフェース状態は、ウェブページ、ユーザインターフェース画面又はネットワーク接続（例えば、ローカルエリアネットワーク又はワイドエリアネットワーク接続など）によってアクセスされる他のリソースに対応することができる。これに関して、ユーザワークステーション１８は、１つ以上のネットワーク接続を介して、ローカルサーバ２０、中央サーバ１２及び／又はデータ分析サーバ１６と動作可能に通信することができる。次に、ウェブページ又は他のツールなどのウェブリソースをユーザワークステーション１８でアクセスして、図３において参照するユーザインターフェース状態を提供することができる。いずれの点においても、ユーザがシステム１０とやりとりするのを可能にするために図３において参照するユーザインターフェース状態がユーザワークステーション１８にて設けられ、これについては後で詳述する。このように、ユーザワークステーション１８は、少なくとも特定の実施形態では、ユーザワークステーション１８を介してのリモートアクセスによって提供される機能を提供するように機能するシンクライアントを備えることができる。

ユーザワークステーション１８は、最初に、薬局ワークフロー管理ログイン画面２８を表示することができる。このような薬局ワークフロー管理ログイン画面２８の一例を図５に示す。これに関して、ユーザワークステーション１８に提示されるログイン画面２８に、ユーザ名フィールド５００とパスワードフィールド５０２を設けることができる。次に、ユーザは、ユーザ名フィールド５００にユーザ名を、パスワードフィールド５０２にパスワードを入力することができる。例えば、施設１４の各ユーザに、システム１０にアクセスするユーザをサービスが識別する独自のユーザ名とパスワードの組み合わせを割り当てることができる。このように、ローカルサーバ２０には、認証されたユーザ名とパスワードの組み合わせの記録が含まれ、システム１０にアクセスしようと試みるユーザに認証されたアクセスを提供することができる。

従って、ユーザ名フィールド５００及びパスワードフィールド５０２に入力されるユーザ名とパスワードの組み合わせには、ユーザ認証情報が含まれていてよい。提供されるユーザ認証情報３８は、ローカルサーバ２０と通信することができる。次に、ローカルサーバ２０は、提供されたユーザ認証情報を処理して（例えば、認証されたユーザ名とパスワードの組み合わせ記録を参照して）、システム１０にアクセスしようと試みるユーザがそうすることを認証されているかどうかを決定することができる。ユーザがそのように認証されている（例えば、提供されたユーザ名とパスワードの組合せが、ローカルサーバ２０のリポジトリに格納される認証されたユーザ名とパスワードの組み合わせと一致する）場合、ローカルサーバ２０は、薬局ワークフローホーム画面３０に関連する情報を含むレスポンス４０を開始することができる。レスポンス４０がユーザワークステーション１８に提供され、その結果、薬局ワークフローホーム画面３０がユーザワークステーション１８に表示される。

図６を更に参照すると、薬局ワークフロー管理者ホーム画面３０の一例が示されている。理解できるように、薬局ワークフロー管理者ホーム画面３０には、ローカルサーバ２０に常駐する薬局ワークフローマネージャが提供する機能に関する複数のリンクが含まれていてよい。本説明において、薬局ワークフロー管理者ホーム画面３０には、中央サーバ１２が提供する管理レポートリソースにアクセスするのに使用するリンク５０４が含まれていてよい。次に、ユーザが管理レポートにアクセスしたい場合、ユーザは管理レポートリンク５０４をクリックすることができる。次に、中央サーバ１２が提供する管理レポートリソースへのアクセスを要求するリクエスト４２がローカルサーバ２０に提供される。次に、ローカルサーバ２０は、管理レポートへのアクセスを要求するユーザに対応する認証情報４４を中央サーバ１２に提供することができる。認証情報４４を中央サーバ１２で分析して、ユーザを認証することができる（例えば、ログイン３８中に提供されるユーザ名及びパスワード情報、ローカルサーバ２０によって提供される他の情報、中央サーバ１２でのユーザクレデンシャル情報管理、及び／又は他の適切な情報に基づいて）。

従って、中央サーバは認証情報４４を使用して、ユーザが中央サーバ１２で管理レポートツールにアクセスするのに適切な許可を有していることを認証することができる。次に、中央サーバ１２は認証キー４６をローカルサーバ２０に戻すことができる。ローカルサーバ２０は、次に、リダイレクトコマンド４８を中央サーバ１２に提供することができる。中央サーバ１２でリダイレクトコマンド４８を受信すると、中央サーバ１２は、ユーザワークステーション１８に、中央サーバ１２が提供する中央レポート画面３２にユーザワークステーション１８をリダイレクトするリダイレクションコマンド５０を提供する。中央レポート画面３２の一例を図７に示す。中央レポート画面３２は、ユーザが中央レポート画面３２にアクセスしている施設に関する静的レポートを提供することができる。これに関して、中央レポート画面３２が提供するレポートは、動的でなくてもよく及び／又は以下により詳細に説明されるような、データ分析サーバ１６が別途提供するデータ分析ツールを提供しなくてもよい。従って、理解できるように、ローカルユーザが中央サーバ１２に対して認証されると、中央レポート画面３２を、中央サーバ１２から直接提供することができる。

更に、データ分析サーバ１６へのアクセスが、中央レポート画面３２にアクセスする所定のユーザに対して認証されると、分析ツールへのリンク５０６を提供することができる。中央レポート画面３２でのリンク５０６を選択して、分析レポート一覧ページへのアクセスのためのリクエスト５２が生成される。これに関して、リンク５０６を選択すると、中央サーバ１２からの分析レポート一覧を要求するリクエスト５２を中央サーバ１２に提供することができる。次に、中央サーバ１２は、リダイレクトコマンド５４をユーザワークステーション１８に提供することによって、ユーザをデータ分析レポート一覧画面３４にリダイレクトすることができる。データ分析レポート一覧画面３４の一例を図８に示す。データ分析レポート一覧画面３４には、データ分析サーバ１６が提供することのできる異なるレポートへの複数のリンク５０８が含まれていてよい。例えば、以下に詳細に説明するように、異なるレポート５０８それぞれを、異なるデータキューブクラス定義によって提供することができる。

データ分析レポート一覧画面３４は、レポート５０８を系統的な形式で提供することができる。これに関して、レポートへのリンク５０８を、レポート一覧５１０に設けることができる。レポート一覧５１０には、レポートリンク５０８の構成のためのフォルダ５１４に配置できるカテゴリ５１２が含まれていてよい。所定の施設及び／又は所定のユーザに特化していてよいフォルダ５１４を生成することができる。これに関して、ユーザは、適切な責務又は役割で、データキューブのコピー及び／又はデータキューブに基づいて生成されるレポートをユーザ又は施設に特化したフォルダに保存するように操作することができる。これに関して、ユーザは、フォルダに保存する際、結果のレポートを所望通りに修正するように操作することができる。修正可能なレポートを、特定の施設からの所定の１人又は複数のユーザのみがアクセスするために、非公開のフォルダに保存することができる。レポート名５０８に対するリンクを選択すると、レポートを要求するリクエスト５６が中央サーバ１２に提供されることができる。

選択されたレポート５０８に対するリクエスト５６を受信すると、中央サーバ１２は認証情報５８をデータ分析サーバ１６に提供してユーザを認証することができる。例えば、認証情報５８は、ログイン３８で提供されるユーザ情報を含むか、又は少なくとも部分的にそれに基づくことができる。データ分析サーバ１６に対するユーザの認証に基づき、選択されたレポートに対応するデータキューブクラス定義を呼び出し、中央サーバ１２でのデータに適用することができる。これに関して、要求される分析レポートは、要求される分析レポートを提供するように設けることができる、データ分析サーバ１６で維持される対応するデータキューブクラス定義を有することができる。これに関して、中央サーバ１２で維持されるデータに適用するためにデータキューブクラス定義を中央サーバ１２に提供して（６０）、要求された分析レポートをデータ分析レポート表示画面３６にレポートを通信すること（６４）によって提供することを容易にすることができる。データ分析レポート表示画面３６のそのような一例を図９に示す。

データ分析レポート表示画面３６には、ユーザワークステーション１８に返送する要求されたデータ分析レポート６４を追加することができる。図９に示す例では、レポート（例えば、この場合は「技術者による検出エラー（Ｄｅｔｅｃｔ Ｅｒｒｏｒｓ ｂｙ Ｔｅｃｈｎｉｃｉａｎ）」）に対応するデータキューブクラス定義の適用に基づいて生成された棒グラフ５１６を提供する。更に、フィルタリングパラメータ５１８を選択して適用して（例えば、レポートを生成するために使用するデータキューブクラス定義によって定義されるように）、グラフ５１６に提示するデータを更にフィルタリングすることができる。これに関して、理解できるように、データ分析レポート表示画面３６に表示されるレポートは、ユーザが様々なパラメータを選択してレポートのリアルタイムの提示を動的に変更できる点で動的なものであってよい。データ分析レポート表示画面３６に提示され得るレポートの他の例には、チャート、グラフ、ピボットテーブル（例えば、データ分析ツールを使用してリアルタイムでユーザが選択可能な軸）、ダッシュボード又は他のデータ分析ツールが含まれていてよい。更に、レポートに関連するこれらの様々なパラメータを表示及び／又は修正する能力は、ユーザの認証プロセス中にユーザに与えられる割り当てられたロール又はリソース特権に少なくとも部分的に基づくことができる。

上で概説したように、データ分析レポート表示画面３６に表示するために配信できるレポートは、中央サーバ１２でのデータへのデータキューブクラス定義の適用に基づいて少なくとも部分的に派生することができる。データキューブクラス定義を使用して、レポートの生成に使用するデータキューブを作成することができる。データキューブは、関連する基礎となるデータテーブル及び／又はデータソースからデータを集約するために使用される多次元データ構造である。「キューブ」という用語を使用するが、データキューブには４以上の次元が含まれていてよい。このように、「キューブ」という用語を使用しても、データキューブを３つのデータ次元に限定しない。むしろ、データキューブは、データ（例えば、用量命令データに関連する上述したフィールドのいずれかを含む）のソースのデータベーステーブル内の関連するフィールドに対応することのできる次元を有することができ、これは３以上の次元を含むことができる。次元には、階層的であってもよい（例えば、データキューブに基づいて生じるレポートにおいてドリルダウン機能を提供するために）レベルを設けることができる。データキューブはまた、基礎となるデータ（例えば、データへの関数適用から生じたもの）に基づく値であるデータ要素を含む尺度を有することもできる。例えば、平均、合計、最小、最大又は他の関数などの尺度を適用して、データキューブに含まれる尺度を生成することができる。これに関して、尺度は基礎となるデータソースにおいて設けてもよく、又は基礎となるデータソースのデータに基づいて計算されてもよい。

データキューブクラス定義を開発してデータ分析プロセスにおいて使用する特定の尺度、次元、レベル、値、インデックス又は他のツールを開発することがでる。尺度、次元、値、インデックスなどのすべてがデータキューブクラス定義におけるデータキューブに対して定義されると、その後、キューブをコンパイルする必要がある。コンパイルでは、データキューブの形式のデータを定義し及び当該データにアクセスするのに要求される必要なすべてのクラスを作成する。最後のステップは、データキューブを構築することである。データキューブを構築するステップでは、すべてのキューブ次元にデータを追加し、その結果、そのデータを閲覧しレポートすることができる。これに関して、バッチジョブを定期的に実行し、データキューブクラス定義が定義したデータキューブに、ソーステーブルからのデータ（例えば、中央サーバ１２に格納されたデータ）を同期させることができる。

データキューブは、構築されると静的であるが、基礎となるデータキューブに基づいて動的なレポート（例えば、テーブル、チャート、グラフ、ピボットテーブル、ダッシュボードなど）を生成するのにユーザが使用することができる。データ分析ツールは、データ分析ツールに関連する様々な機能を実施するのに使用することができる様々なレベルの責務を有することができる。例えば、ユーザを、データキューブクラス定義を作成することを可能にする構築ツールを使用するよう認証することができる。加えて、ユーザを、構築されたデータキューブに基づいて、レポート、ピボットテーブル又は他の分析ツールの作成を可能にする分析ツールを使用するよう認証することができる。更に、ユーザは、予め定義されたレポート、ピボットテーブル、ダッシュボード又は他の予め定義された分析レポート出力（分析ツールによって設計されたもの）からの結果を表示する閲覧ツールを使用することができる。すべてのレベルへのアクセスを容易にする管理者アクセスレベルを設けることができ、また他の特定のロールをデータ分析ツールの複数の（ただし全てに満たなくてもよい）責務レベルに関連する権限を伴って開発することができる。

図４を更に参照すると、システム１０によって、委譲された認証プロセス４００を使用することができる。委譲された認証プロセス４００を、図４にフローチャートの形式にて示す。委譲された認証プロセス４００は、中央サーバ１２にアクセスするのに十分な資格を与えられた認証ユーザを委譲された形式で認証することができ、その結果、中央サーバ１２が委譲された認証を行うと、分析サーバ１６は中央サーバ１２に格納されたデータに関連するデータ分析ツールを提供する。プロセス４００は、ユーザがローカルサーバ４０２にログインすることによって開始することができる。上述したように、ローカルサーバ４０２へのログインには、ユーザ名とパスワードの提供が含まれていてよい。同様に、ローカルサーバには有効なユーザ名とパスワードの組み合わせのデータベースが含まれ、ユーザがローカルサーバにアクセスすること認証されているかどうかを決定することができる。ローカルサーバ４０２に正常にログインすると、ユーザにローカルサーバでレポートツールへのアクセスをリクエストする（４０４）オプションを提示することができる。ローカルサーバでレポートツールへのアクセスリクエストを行う（４０４）と、ユーザを中央サーバレポートページにリダイレクトする（４０６）。これに関して、中央サーバは、ユーザに表示するウェブページを提供することができる。

ユーザが分析レポートにアクセスするのに十分な資格を有している場合及び／又は中央サーバレポートページがユーザが中央サーバにアクセスしているサイト用に構成されている場合には、中央サーバレポートページには、分析レポートへのリンクが含まれていてよい。ユーザが中央サーバからの分析レポートをリクエスト（４０８）すると、中央サーバは、その後中央サーバのデータベースに格納される認証トークンを作成する（４１０）。中央サーバはまた、データ分析ツールを呼び出すこともできる（４１２）。データ分析ツールを呼び出すと（４１２）、作成されたトークン（４１０）は、データ分析ツールが呼び出される（４１２）ときにデータ分析サーバに渡される。

これに関して、データ分析サーバがデータ分析サーバに提供されたデータ分析ツールへのアクセスリクエストを受信すると、データ分析サーバは、暗号化サービスプロバイダを開始（４１４）し、データ分析ツールへのユーザアクセスリクエストの委譲された認証を実施する。具体的には、暗号化サービスは、中央サーバと、ユーザアクセスリクエストから受信したトークンに関する情報とをコンタクトさせることができる。トークンが、中央サーバのデータベースに提供されたトークンと一致する場合、ユーザは認証され得る。次に、有効なトークンを中央サーバから削除して（４１８）、その特定のトークンが認証されることなく今後使用されることを防止する。これに関して、ユーザが中央サーバからの分析レポートへのアクセスをリクエスト（４０８）すると、トークンが作成されて（４１０）、中央サーバに格納される。ユーザをリダイレクトしてデータ分析ツールを呼び出し（４１２）、作成された対応するトークンがリクエストとともに提供される。これに関して、データ分析サーバが認証リクエストを受信すると、暗号化サービスプロバイダは、中央サーバにコンタクトしてリクエストに提供されたトークンがデータベースに作成されたものと一致するかどうかを決定することができる。これに関して、中央サーバに格納された対応するトークンを有しないトークンを使用したデータ分析サーバにアクセスするための不正なリクエストは認証されない場合があり、このように、認証されないユーザが不正又は期限切れのトークンでツールにアクセスする能力を低減する。これに関して、トークンを暗号化サービスプロバイダが分析してリクエストされたユーザアクセスが認証されるかどうかを決定する（４１６）。次に、中央サーバからの認証に少なくとも部分的に基づいて、ユーザをデータ分析サーバで認識することができる（４２０）。すなわち、ローカルサーバ４０２に提供されるログイン情報を、次に中央サーバに渡すことができる。

加えて、中央サーバはユーザ情報をデータ分析サーバに提供してユーザを識別することができる（４２０）。この情報には、例えば、以下に説明するようにユーザを識別することのできるセッション変数、並びに／又はユーザの資格に基づいて当該ユーザが利用可能なロール及び／若しくはリソースに関する情報が含まれる。これには、データ分析サーバにアクセスしようと試みるユーザ及び／又は施設を定義することが含まれる。次に、ユーザ識別に基づいて、データ分析サーバからデータ分析サーバにアクセスしようと試みるユーザにロール及びリソースを割り当ててデータ分析ツールを呼び出すことができる（４２２）。これに関して、ユーザ識別に基づいて適切なデータキューブを呼び出すことができ（４２４）、このデータキューブは、次に当該ユーザ識別に基づいて中央サーバデータに適用される。上述したように、適切なデータキューブは、所定の施設からのユーザがデータ分析ツールを使用するときにその施設に対応するデータにのみアクセスできるように、中央サーバでデータをフィルタリングすることができる。更に、（４２２）で割り当てられるロール及びリソースに応じて、複数のデータキューブのうち異なるものをユーザに提供してデータに関する様々な異なるレポートを実行することができる。次に、現状のデータキューブに基づいて分析レポートを生成し（４２６）、ユーザにレポートを提示することができる（４２８）。

具体的には、データ分析サーバに提供されたデータ分析ツールへのユーザアクセスリクエストを識別する際、認証には、適切なロールが割り当てられたデータ分析ユーザとしてユーザがデータ分析環境にログインすることが含まれていてよい。例えば、委譲された認証中に、リクエストユーザは、＜ｃｕｓｔｏｍｅｒＩＤ＞｜＜ｕｓｅｒＩＤ＞｜＜ｕｓｅｒｎａｍｅ＞の形式のユーザ名でログインすることができ、ここで、＜ｃｕｓｔｏｍｅｒｉｄ＞は、ユーザが中央レポートページにアクセスしている顧客ＩＤ（例えば施設に対応する）である。例えば、ユーザ識別をデータ分析サーバに伝達されるセッション変数の一部として提供することができる。顧客ＩＤではなく、０を使用して中央サーバから直接データ分析にアクセスするユーザをサポートするためにこのフィールドに追加してもよく、＜ｕｓｅｒＩＤ＞は、ユーザに対応するユーザＩＤであってよく（例えば、ユーザが中央サーバから直接データ分析ツールにアクセスすることをサポートするために０を再び使用する）、ｕｓｅｒｎａｍｅはユーザのログインＩＤであってよい。一例として、顧客ＩＤが５で、中央サーバのユーザＩＤが１０の管理者ユーザは、「５｜１０｜Ａｄｍｉｎｉｓｔｒａｔｏｒ」としてログインされる。

次に、データ分析ツールを使用してレポートを生成するためにデータにアクセスするとき、ユーザ識別（例えば上述のようなもの）を使用して、データキューブクラス定義が適用されるデータを制限し又はレポートを生成するときにユーザがアクセスすることのできるデータを制限することができる。例えば、一実施形態では、他のすべてのデータキューブクラス定義が従属する基本キューブクラス定義を提供することができる。これに関して、すべてのデータキューブクラス定義は、基本キューブクラス定義から継承されてもよい。ローカルサーバからの不正アクセスを防ぐため、開発されるすべてのデータ分析ツールのデータキューブクラス定義は、特別なセキュリティフィルタークラス定義を含む基本キューブクラス定義から継承される。これに関して、基本キュークラス定義には、キューブ定義に含まれる他の次元に加えて、デフォルト次元として組織識別子及び顧客識別子が含まれていてよい。基本キューブクラス定義はこれら２つのプロパティを使用して、ユーザ認証プロセス中に受信するユーザ識別情報に基づいて、特定の顧客又は組織アカウントからの記録のみを含む。これは、ユーザが中央サーバ上の他の顧客データにアクセスすることを防止するためのセキュリティ機構として機能する。

例えば、組織又はサイトデータへのユーザのアクセスに基づいて中央サーバのデータをフィルタリングするために、基本キューブはユーザが組織レベルのユーザかサイトレベルのユーザかを検出する。その評価をもとに、ユーザが属する組織又はサイトのいずれかに基づいて、多次元式フィルタストリングが組み立てられる。フィルタストリングが組み立てられると、多次元式フィルタを基本キューブ（例えば、これは組織ＩＤ又は顧客ＩＤに対応する次元を含む必要がある）内のすべてのデータに適用して、任意のレポートにおいてユーザが見る情報を制限する。このように、基本キューブクラス定義は、認証プロセス中に受信するユーザ識別情報と関連して、ユーザが属する又はユーザがツールにアクセスしている施設（又は組織）にのみ対応するデータにユーザのアクセスを制限するように役立つ。このように、データ分析ツールは、複数の施設に対応する集約されたデータ上で操作する一方で、他の全てのデータキューブクラス定義が従属する基本キューブクラス定義は、ユーザの施設に対応するデータへのアクセスを制限するように役立つことができる。

内部ユーザ（例えば、中央サーバから直接データ分析ツールにアクセスするユーザ）も、データ分析ツールからデータにアクセスできる必要があるため、基本キューブクラス定義はまた、ユーザがローカルサーバから又は直接中央サーバを使用して環境にアクセスしているかどうかも検出する。これは、ユーザがデータ分析ツールへのアクセスをリクエストする所定のユーザセッションのためのセッション変数に、予想されるパラメータが追加されているかどうかを決定することによって、これを達成することができる。そうであれば、アクセスはローカルサーバを経由しているとみなされる。そうでない場合には、アクセスは中央サーバ画面を経由しているとみなされ、中央サーバからデータ分析ツールにアクセスしているユーザに正しいロールが割り当てられているかどうかを確認するために、ユーザセッション定義に属するロールの確認が行われる。

加えて、保護対象保健情報（ＰＨＩ）パラメータを使用して、ＰＨＩ情報がキューブによって公開されているかどうかを表示することができる。これにより、生成されるレポートがＰＨＩ情報を含むキューブを識別することが可能になる。ＰＨＩ情報を含むキューブはまた、キューブにアクセスする特定のユーザに帰属する特定のリソースを要求することもできる。これにより、ＰＨＩを含むこれらのキューブから派生するピボットテーブル及びダッシュボードへのアクセスを制限することになる。これに関して、医療情報の交換に関する特別な関心事には、患者のプライバシーを維持することが含まれる。これは医療情報の交換に関連するからである。例えば、医療情報には、患者識別情報（例えば、ＰＨＩを潜在的に含む）が含まれていてよい。これに関して、医療情報の頒布は、ＰＨＩ又はその他のプライバシーに関する事項を伴う医療情報の伝達を禁止するとのできる規制法（例えば、米国における医療保険の移転とそれに伴う責任に関する法律（ＨＩＰＰＡ））によって制限を受ける場合がある。ＨＩＰＡＡはＰＨＩを定義することができると同時に、ここで使用されるＰＨＩには、ＨＩＰＡＡ定義に含まれるデータのみならず他のデータも含まれることを理解することができる。例えば、患者識別情報（例えば、患者名、患者識別番号など）は、ＰＨＩとして定義できる。

更に、データキューブクラス定義には、データソースからのデータに適用されるデータ変換が含まれていてよい。これらの変換には、基礎となるソースデータに基づいて計算される尺度を生成することが含まれていてよい。変換には、ソースデータへの変更も含まれていてよい。例えば、完全腸管外栄養（ＴＰＮ）用量に関連するある特定の例では、特定の用量命令記録フィールドは、対応するデータキューブクラス定義によって作用され得る。これに関して、構築プロセス中にデータキューブクラス定義は、所定の用量命令フィールド（例えば、用量記載フィールド）を別のフィールド（例えば、用量薬品名フィールド）からの値に置き換えることができる。この変換は、特定の用量タイプ（例えば、用量命令がＴＰＮ命令であるか、又はその命令に含まれる薬品に基づくかを示す記録フラグによって決定されるＴＰＮ用量）にのみに適用することができる。このように、キューブ構築中にソースデータテーブルからの記録を、その記録が適切なフィールド（例えば、上記の例に従うと「用量記載」、「ＴＰＮ」、及び「用量薬品名」）を含んでいるかを決定することになる。記録がデータ変換を適用するＴＰＮ命令であると決定されると、データ分析サーバはＴＰＮフィールドを確認して、フィールドが１に設定されている（用量がＴＰＮである）場合には、フィールド「用量薬品名」の値を「用量記載」フィールドにコピーすることができる。

加えて、各データキューブクラス定義は、データを構築するときに、キューブが「データ除外」フラグと指定されたサイトからの記録をローディングしないようなものである。これに関して、基本キューブクラス定義は、記録がデータ除外指定を有する顧客サイト用であるかどうかを決定し、そうであれば当該記録がローディングされるのをスキップする。データ除外指定５２２は、図１０に示すサーバ詳細ページ５２０に設定される。

これに関して、更に図１０を参照すると、様々なサーバがアクセスしたときにデータ分析ツールの挙動構成を可能にするサーバ詳細ページ５２０が示されている。これに関して、データ分析ツールへのユーザアクセスを提供することができるローカルサーバのリスト５２４を設ける。リスト５２４における各サーバについて、サーバ構成フィールド５２６を提供する。このフィールド５２６において、サーバに関する詳細（例えば、ロケーションアドレス、サーバステータス、課金情報、アカウント番号、サーバ構成詳細など）を構成することができる。具体的には、分析アクセス選択フィールド５２８によって、管理者はデータ分析ツールへのアクセスを有する所定のローカルサーバからのユーザに関連する許可を設定することができる（例えば、それによってデータ分析ツールへのリンク５０６を図７の中央レポート画面３２に設けるかどうかを決定する）。更に、分析アナライザ選択フィールド５３０を設け、これを使用してデータ分析ツールのアナライザにアクセスを有する所定のローカルサーバからのユーザに関連する許可を設定することができる（例えば、そこでは、レポート、ダッシュボード、ピボットテーブルなどを生成することができる）。加えて、データソースリスト５３２を、リスト５２４内の所定のサーバの各特定データソースに関連して設けることができる。

データキューブクラス定義の参照に戻ると、特定の有用なデータ変換技術を、データキューブクラス定義で使用するために設けることができる。例えば、保護対象保健情報（ＰＨＩ）パラメータを設けて（例えば、すべてのキューブに）、キューブがＰＨＩ情報を公開しているかどうかを識別することができる。ＰＨＩが存在することを示すパラメータが真であると決定された場合には、キューブはＰＨＩフィールドを含み、そうでない場合には、キューブはＰＨＩフィールドを含むとはみなされない。ＰＨＩパラメータは、キューブクラス定義を適用する基礎となるデータソースに基づいて動的に生成することができる（例えば、ソースデータがＰＨＩを有すると決定されたかどうか）。

加えて、デルタタイム関数を設けることができる。デルタタイム関数を使用して２つの時間の間の時間差を計算することができる。各時間の値を、関数にパラメータとして渡し、その時間差（例えば、分、時間、日、秒などで測定されるときの）を次元の値として返すことができる。このように、時間関数を使用するキューブ尺度が生成されると、抽出される時間尺度を表示する尺度名も生成することができる。例えば、「ＤｅｌｉｖｅｒｅｄＴｉｍｅＭｉｎｕｔｅｓ」と呼ばれる尺度を、患者に用量が送達された時間と薬局で受け取った時間との間の差として定義することができる。この例を続けると、キューブ尺度「ＤｅｌｉｖｅｒｅｄＴｉｍｅＭｉｎｕｔｅｓ」を有するデータキューブクラス定義は、特定のメソッドコールが実際の計算を実施し、ソースデータ要素が比較される時間値であるような命令を有することができる。例えば、特定メソッドコールは、比較される定義された時間尺度の差を返して、その値を正の整数として戻すことができる。

更に、１つ以上のカスタム時間機能を生成することができる。カスタム機能を生成して任意の数の所望の結果を評価することができる。経過時間を評価するために複数の入力に依存するカスタム時間レポート機能については、４つの時間入力をとることができるカスタム時間機能を設けることができ、これは４つの入力値を用いたコード化基準に基づいて用量調製時間を評価する。このメソッドは４つの定義された時間値をとり、それに特化した計算を実施することができる（例えば、４つの入力値によって定義されるプロセスの様々な段階で、時間用量を評価する）。

加えて、データキューブクラス定義ごとに記録フィルタリングを設けることができる。これにより、記録フィルタリングは必要でない記録をキューブデータセットから削除することができる。これは、ＷＨＥＲＥ句をＳＱＬ文に追加するのと同様に考えることができる。これに関して、記録を含めるべきかどうかを決定するために「ｉｆ」文を設定することにより、キューブを構築するときに記録をファクトテーブルから除外することができる。例えば、一例では、データキューブクラス定義は、キューブ内の１つ以上の所定の次元の内容（例えば、タイプ及びエラーカテゴリ）に基づいて記録をフィルタリングすることができる。

加えて、キューブ定義には、ユーザがピボットテーブル又はダッシュボード内でドリルダウンするときにユーザに表示するためのフィールドを定義するリストタグが含まれていてよい。ピボットテーブルは複数の定義されたリストを有することができる。キューブに基づいてピボットテーブルを定義するとき、ピボットテーブル考案者はエンドユーザがピボットテーブル上でドリルダウンするときに表示するリストを選択することができる。そのピボットテーブルに基づくダッシュボードは、ピボットテーブル設計中に特定されるリストを表示するためにデータにおいてドリルダウンする機能を継承することもできる。

更に、データキューブクラス定義には、所定のデータキューブのためのデータ内に含まれる患者情報を匿名化するために使用する演算が含まれる。例えば、ハッシュ関数などを患者情報に適用して、それによって、データキューブ内の得られたデータを患者の匿名化にすることができる。更なる実施形態では、データキューブクラス定義のためのソースデータは、患者識別情報が除去された（例えば、ハッシュ関数などによって）データソースであってもよい。

加えて、ユーザがデータ分析ツールにアクセスすると、データ分析ツールにアクセスしているユーザ及びセッション中にアクセスされる様々な特定のリソースに関するロギング情報を提供するログイベントを生成することができる。これに関して、所定のユーザセッション及び／又はユーザセッション内で発生するナビゲーションのためのログエントリを生成することができる（例えば、中央サーバ１２及び／又はデータ分析サーバ１６でのロギングモジュールによって）。これらのログセッションは、特定のセッションに関するアクセスを提供してユーザを定義することを達成し、且つセッション中のユーザの特定のナビゲーションに関する詳細を提供することができる。次に、ユーザログをレビューして、どのユーザアクセスがそのアクセスに関連するどのリソースと特定のパラメータとにアクセスしているかを決定することができる。これに関連して、ユーザログの一実施形態に対応するスキーマ６００を図１１に示す。

従って、図１１を更に参照すると、ログ記録を生成するのに使用するスキーマ６００にはユーザによる各セッションのために作成された中央ユーザセッションログ６１０が含まれていてよい。中央ナビゲーションログ６２０の形式のサブ記録を各中央ユーザセッションログ６１０のために生成して、中央ユーザセッションログ６１０に対応するセッション中のユーザの特定のナビゲーションを追跡することができる。これに関して、セッションログ記録を、中央ユーザセッションログ６１０のためのスキーマに従って生成することができる。従って、セッションログ６１０には、ユーザが使用するブラウザを格納する文字列としてプロパティ「ブラウザ情報」が含まれていてよい。セッションログ６１０にはまた、ログされるユーザセッション（例えば、ユーザから受信するトークンに対応する場合がある）に従事するのに使用される暗号化サービスプロバイダセッション識別子への参照に対応するプロパティ「ＣＳＰセッションＩＤ」が含まれていてよい。ログ６１０にはまた、このセッションに関連するユーザにリンクするプロパティ「中央ユーザ」が含まれていてよい。これは、該当する場合、中央サーバからサポートユーザとして中央サーバからツールに直接アクセスする中央ユーザを示すことができる。ログ６１０にはまた、クライアントアプリケーションからこのセッションに関連するユーザへのリンクを含むプロパティ「クライアントユーザ」も含まれていてよい。ログ６１０にはまた、ユーザがツールにアクセスしている顧客の識別を含むプロパティ「顧客」も含まれていてよい。ログ６１０はまた、ユーザがツールにアクセスしているクライアントについての特定の詳細を得るためにサイト統計を含むプロパティ「顧客クライアント情報」が含まれていてよい。ログ６１０はまた、セッションが入力された日を含むプロパティ「入力日」が含まれていてもよい。ログ６１０にはまた、セッションが入力された日／時間を含むプロパティ「入力日時」が含まれていてよい。ログ６１０には、セッションが最後にアクティブ又は更新された日／時間に対応するプロパティ「最終アクティブ日時」が含まれていてよい。ログ６１０には、ユーザがローカルサーバからリダイレクトされた場合に顧客ソースに関する情報を提供するプロパティ「ソース」が含まれていてよい。ログ６１０にはまた、上述した独自に識別可能なトークンに対応するものとしてプロパティ「トークン」が含まれていてよい。更に、ログ６１０には、アクセスされたデータ分析ツールの特定のアプリケーションの識別を含むプロパティ「ウェブアクセスタイプ」が含まれていてよい。

更に、各セッションログについて、セッションアクティビティ又はナビゲーションに対応する中央ナビゲーションログ６２０を含むサブ記録を生成することができる。中央ナビゲーションログ６２０には、例えば、ログインされるナビゲーションに関連する中央ユーザセッションログ６１０にリンクするプロパティ「中央ユーザセッション」などのプロパティが含まれていてよい。ログ６２０には、アクセスされるクラスに対応するプロパティ「クラス関連ＵＲＬ」も含まれていてよい。プロパティ「患者情報を含む」は、アクセスされているリソース（例えば、ページ、レポート、ツール）がＰＨＩ情報を含んでいるかどうかに関する真偽を表示するものであってよい。これに関して、ＰＨＩを含むレポートが実行されている場合には、パラメータ「ＰＨＩを含む（ＨＡＳＰＨＩ）」を１に設定するか、レポート定義フィールド「ＰＨＩを含む（ＣｏｎｔａｉｎｓＰＨＩ）」を１に設定することができる。ログ６２０にはまた、ユーザがツールにアクセスしている顧客を示すプロパティ「顧客」も含まれていてよい。プロパティ「データ分析アクセス」は、使用するデータ分析ツールからのリソース（例えば、呼び出されたデータキューブ定義などを含む）を示すものであってよい。プロパティ「入力日」はセッションが入力された日付に対応し、プロパティ「入力日時」はセッションが入力された日／時間に対応することができる。ログ６２０には、もしあれば、アクセスされるレポートの識別を示すプロパティ「レポート」も含まれていてよい。プロパティ「エクスポートされたレポート」には、レポートがエクスポートされたかどうかの表示が含まれていてよい。プロパティ「レポートパラメータ」には、レポートを実行するとき又はそうでなければデータ分析ツールを使用するときにユーザが選択するパラメータも含まれていてよい。プロパティ「レポートクエリ」には、レポートを生成するために実行されたクエリの識別が含まれていてよく、「レポート記録カウント」には、レポートによって返送される記録が含まれていてよい。プロパティ「サーバプロセスタイム」は、ｍｓ（ミリ秒）単位の処理時間に対応することができる。プロパティ「ソース」には、ユーザがローカルサーバからリダイレクトされた場合の顧客ソースの表示が含まれていてよい。

前述の説明と関連して、本明細書に記載されるデータ分析ツールは、用量命令データに関連して複数の異なる内容において使用できることが理解できる。このように、本発明を通じて用量命令データを参照しているが、このようなデータは広範囲のデータ分析を含むことができ及び／又は提供することができる。例えば、上述するように、データ分析ツールを呼び出することができる用量命令データには、用量命令、用量命令の調製、用量命令調製中に使用する製品に関する情報又は任意の他の関連情報を含むことができる複数の異なる用量命令データクラスが含まれていてよい。これに関して、複数の異なるカテゴリのデータキューブクラス定義をデータ分析ツールに設けることができることを理解することができる。重要なことには、そのようなすべてのデータキューブクラス定義は、所定のユーザに対応する特定のデータに施設（又は組織）への選択的且つ安全なアクセスを許可する基本キューブクラス定義から従属することができる。

例えば、複数のデータキューブクラス定義のカテゴリを設けることができる。例えば、データキューブクラス定義は、例として一般的な薬局のワークフローアクティビティ、薬局のパフォーマンスメトリクス、薬局の除外、薬局の使用及び廃棄、製品及び治療に関連するデータ、コンプライアンスデータ、及びユーザログに関連するものであり得る。これに関して、一般的な薬局ワークフローアクティビティカテゴリにおけるデータキューブクラス定義の例には、用量命令、用量命令アイテム、用量調製情報、用量請求アクティビティ、用量スキャンイベント、用量検証履歴及び手順概要に関する基本統計に対応するデータキューブクラス定義が含まれていてよい。これに関して、基本用量統計に対応するデータキューブクラス定義には、例えば、用量投与時間、用量が一連の用量の第１用量であったかどうか、用量経路（例えば、静脈、口腔、筋内など）、用量が危険用量であるかどうか、用量が高リスク用量であるかどうか、用量に対応する看護ユニット、用量がＳＴＡＴ（迅速）用量であるかどうか、用量が完全腸管外栄養（ＴＰＮ）用量であるかどうか、ＴＰＮ用量のタイプ、用量に未知の薬品が含まれているかどうか、用量を調製した技術者、用量調製に利用したワークステーション、用量が在庫用量であるかどうか、用量が希釈用量であるかどうか、用量状態、用量調製日、用量開始時間及び用量開始分に関連する用量次元が含まれていてよい。更に、上述の次元のいずれも、当該次元の正規化されたバージョンが含まれていてよい（例えば、正規化された薬品名、正規化された量、正規化された単位などの場合）。更に、用量命令概要データを提供するいくつかのデータキューブクラス定義には、用量の総量、用量の最終量、用量のＱＳ（適量）量、ＱＳ希釈剤名、在庫用量カウント、希釈用量カウント、用量再作業数、用量のインライン検証、調製された用量ごとの画像数、薬剤師が完全に調合した用量数、手作業で添加した用量数、資料請求を受けた用量数、広範型（未承認）薬品名を有する用量数、状態別用量数、経由別用量数、用量命令記録用の付属物の数及び正規化された用量説明に関する尺度が含まれる。用量命令アイテムに関するデータキューブクラス定義について、データキューブクラス定義は、用量状態（例えば、患者に実際に送達されていないという我々の記録をフィルタリングするための）、用量説明、正式薬品名、基本単位及び希釈剤に基づいて正規化された用量説明、用量が保存用量であるかどうか、用量が希釈用量であるかどうか、用量が危険用量であるかどうか、用量が高リスク用量であるかどうか、用量の総量（例えば、寄与少量製品を含む）、用量の最終総量（例えば、用量命令のために電子カルテシステム（ＥＭＲ）又は病院情報システム（ＨＩＳ）によって特定されるときのもの）、ＱＳ用量及びＱＳ希釈剤名に対応する次元に関連するものであってよい。用量調製情報に関連するデータキューブクラス定義には、用量調製に使用する調製モード、用量を調製した時の調製モードオプション、及び用量の計算ＱＳ量に対応するデータ次元が含まれていてよい。データキューブクラス定義は、検証中に薬剤師が用量を請求する（例えば、用量を検証するセッションを有する別の使用者から）という事象に関連し得る。これに関して、用量請求データキューブクラス定義には、検証中に用量が請求されたかどうか、用量を請求した個人が用量を処分したかどうか、請求が成功又は失敗した理由、請求が他のユーザの請求を上書きしたかどうか、請求のアクティブ時間、上書きするユーザ、上書きされたユーザ及び用量識別子に対応するデータ次元が含まれていてよい。用量スキャンイベントに関連するデータキューブクラス定義には、スキャンイベント名、用量命令識別子、製品ロット識別子、カタログ識別子、スキャンのためのユーザ識別子及びイベントターゲット（例えば、用量命令、製品ブログ又はキットイベントタイプを決定するために計算されたもの）に関連するデータ次元が含まれていてよい。用量検証履歴に関連するデータキューブクラス定義には、用量を検証するユーザのユーザ識別子、用量が検証される日／時間、検証結果、検証中（例えば、リキュー、取消及び再作業のための）に提供された理由、用量識別子、検証タイプ、用量の処分、再調製の理由及び拒否された製品ログに対応するデータ次元が含まれていてよい。手順記録に関連するデータキューブクラス定義には、用量のエントリー日時、用量の完了日時、用量調製のために使用した技術者のユーザ識別子、用量調製に利用したワークステーションのワークステーション識別子、用量名、中央の正式な手順ＩＤ（例えば、調製の際にユーザに提示された手順に対応するもの）、手順タイプ、完了アクションカウント、要求アクションカウント、全アクションカウント及び完了時間が含まれていてよい。

加えて、複数のパフォーマンスデータキューブクラス定義が設けられ、それには用量のターンアラウンドタイム及びシステムパフォーマンスに関する情報が含まれていてよい。用量ターンアラウンドタイムに関するデータキューブクラス定義について、データキューブには、用量調製に利用されたワークステーション、調製場所名、技術者名、患者の場所、用量に対応する看護ユニット、用量の優先順位、用量がＳＴＡＴ用量であるかどうか、用量が危険用量であるかどうか、用量におけるアイテム数、用量が保存命令であるかどうか、用量薬品名、調製日／時間に関連する次元が含まれていてよい。更に、複数の尺度が調製平均時間、送達時間、調製待ち時間、インライン検証又は再作業後の調製再開時間、用量分配までの時間、用量検証の平均時間、用量を振り分ける平均時間を含めた用量ターンアラウンドタイムに関連するデータキューブクラス定義のために設けられていてよい。システムパフォーマンスに関するデータキューブクラス定義には、ログの時間／日、セッションの計算された記録長さ、関数名、データ分析サーバ実行平均時間、クライアントサーバ実行平均時間、データ分析サーバ最長実行時間、クライアントサーバ最長実行時間、データ分析サーバ最短実行時間、クライアントサーバ実行最短時間及び実行カウントに対応するデータ次元が含まれていてよい。

更に、用量例外に関連する複数のデータキューブクラス定義を設けることができる。例として、防止されたエラー（例えば、スキャンエラー）、検出されたエラー、バイパスの理由、用量命令の修正及びアラートに関連するデータキューブクラス定義を挙げることができる。従って、防止されたエラーは、人間の介入なしに自動的に薬局ワークフロー管理アプリケーションによって特定されたエラー（例えば、スキャンエラーなど）に対応することができ、検出されたエラーには用量レビュー中の薬剤師などの薬局ワークフロー管理アプリケーションと関わる人間によって識別されたエラーが含まれていてよい。スキャンエラーに関連するデータキューブクラス定義には、用量調製中に発生した防止されたエラーを含む用量、用量カテゴリ、用量識別子、スキャンされたバーコード、スキャン正式製品情報、スキャン製品ログ情報、技術者情報及びワークステーション情報に関連するデータ次元が含まれていてよい。検出されたエラーに関連するデータキューブクラス定義には、薬剤師の確認部署で発生する検出エラーデータが含まれていてよい。検出されたエラーデータキューブクラス定義内に含まれるデータ次元には、用量を再調製する理由、薬剤師情報、技術者情報、ワークステーション情報、調製場所、用量に関連する看護ユニット、用量の投与経路、用量が危険用量であるかどうか、危険用量のタイプ、用量がＴＰＮ命令であるかどうか、用量説明が含まれていてよい。バイパス理由に関連するデータキューブクラス定義には、バイパス印刷操作に関係した用量に関する情報が含まれていてよく、それによって、当該用量命令は、薬局ワークフロー管理アプリケーションによって受信されると、ラベル印刷者が従来の形式で用量命令をプリントするためにバイパスされる。このように、バイパス理由データキューブクラス定義のデータ次元には、用量がバイパスされたことの表示、命令入力日時、用量命令に対応する薬品情報、データ命令のソースに関する情報等が含まれていてよい。用量命令修正に関するデータキュークラス定義には、投与日／時間の更新、用量中断、用量の優先度変更、用量の保留状態への又は保留状態からの移動、早めの有効期限を有する在庫品を使用することによる用量の有効期限日／時間、システムが自動的に又はユーザが意図的に用量を調整したかどうか、修正者名、修正を必要とした理由（例えば、サイトが修正理由を入力するよう構成されている場合）を含めて、どのような用量修正を行ったかを含むデータ次元が含まれていてよい。用量アラートに関連するデータキューブクラス定義には、用量が調製プロセス中にアラートを受けたかどうか、及び用量アラートに関連する傾向を決定するのを可能にすることができる他の用量識別情報に対応するデータ次元が含まれていてよい。他のデータキューブクラス定義には、用量命令、患者、薬品又は薬局ワークフロー管理アプリケーションが格納するデータのいくつかの他の部分に関する受信アラート（例えば、薬局ワークフロー管理システム内又は外部のアラート提供者からのもの）に関するデータ次元が含まれていてよい。

データキューブクラス定義は、薬局での使用及び廃棄メトリックスにも関連することができる。例としては、製品廃棄、薬品廃棄及び姉妹製品に関連するデータキューブクラス定義が含まれていてよい。従って、製品廃棄データキューブクラス定義には、製品調製場所、調製技術者情報、用量状態、用量名、用量における薬品のＮＤＣコード、用量の総量、用量の現行量、用量の有効期限、調製用量数、未使用用量比（すなわち、現行量を総量で割ったもの）、用量コスト（例えば、薬品又は用量に関連する製品の正式記録から参照されるもの）及び用量が複数使用用量であったかどうかといった未使用／有効期限切れ製品からのデータに対応するデータ次元が含まれていてよい。例えば、製品廃棄クラス定義から生成される製品廃棄データキューブに基づいて得られたレポートには、所定の期間に渡って廃棄された薬品量及び／又は対応する廃棄に関するコストの集計が含まれていてよい（例えば、基礎となるデータ及び／又はデータキューブクラス定義において定義される尺度を使用する）。薬品廃棄データキューブクラス定義には、製品ログ識別子、エントリー日、有効期限、アクティベーション日、用量の超過使用時間数、薬品名、用量の量、用量単位、用量が危険用量であるかどうか、用量が高リスク用量であるかどうか、及び用量が希釈用量であるかどうかに対応するデータ次元が含まれていてよい。これに関して、超過使用時間データ次元は、有効期限日とアクティベーション日時との間の差異を含む計算された尺度であってもよい。

データキューブクラス定義の製品カテゴリ及び治療カテゴリには、治療概要及び薬品の組み合わせに関連するデータキューブクラス定義が含まれていてよい。従って、治療概要に関連するデータキュークラス定義には、例えば、顧客識別子、ソース識別子、用量エントリー日、用量の薬品名、用量説明及び治療ＩＤを含む平均継続時間（例えば、日数、用量数又は用量総量）に関して薬物療法の実例を調べる能力に対応するデータ次元が含まれていてよい。薬品組合せデータキューブクラス定義には、共に与えられたときの薬品の組み合わせの頻度を示す「クロスタブ」が含まれていてよい。このデータキューブクラス定義のデータ次元には、顧客識別子、ソース識別子、用量のエントリー日、用量に関連する薬品名、用量の量、用量単位及び用量識別子が含まれていてよい。

複数のデータキューブクラス定義はコンプライアンス追跡に関連することができる。例としては、計画タスク履歴及び重量測定に関連するデータキューブクラス定義を挙げることができる。計画タスク履歴データキューブクラス定義には、計画されたタスクでのコンプライアンス追跡をワークステーションに関して完了することを可能にすることのできるデータ次元が含まれていてよい。これに関して、データキューブのデータ次元には、ワークステーションタスク、失敗したタスク用量カウント（例えば、クリーンなタスクが定刻に完了しないことによる不良用量数など）、完了したタスク情報（例えば、ユーザ、時間、ワークステーション、タスクが期限超過したかどうか、及び期限超過時間を含む）、ユーザが期限超過ワークステーションで何回用量を調製したか、頻度タイプ、頻度値、前回の完了日／時間、前回の期限日時、次回の期限日時が含まれていてよい。重量測定データキューブクラス定義には、重量測定値記録用量調製ワークステーションに対応するデータが含まれていてよい。更に、コンプライアンス追跡に関連するデータキュークラス定義によって、例えば用量タイプ、用量調製日、技術者、場所又は他の適切な次元など複数の異なるデータ次元に基づいて用量をフィルタリング及び／又は検索することができる。更に、コンプライアンス追跡に基づいて生成される動的レポートによって、ユーザが様々な次元レベルを通じてドリルダウンすることを可能にすることができる。所定のレベルで、ユーザは、所定のデータセットを含む個々の用量命令記録を選択して閲覧することができる（例えば、チャートセル又はグラフ部分は所定の用量数に対応することができ、これはユーザによる選択に基づいて当該チャートセルのグラフ部分によって参照される特定の用量命令記録のリストとして明示できる）。すなわち、レポートによって、ユーザは様々なパラメータを選択又は定義することができ、様々なパラメータの選択を使用するユーザによって確立された基準を満たす用量リストにユーザがアクセスすることが可能である。コンプライアンス追跡データキューブには、特定の用量命令記録のリストに含まれる所定の用量命令に対応する用量命令ログをユーザが検索できるリンクが含まれていてよい。用量命令ログには、選択された用量命令に関する任意の又は全ての情報（例えば、用量命令自体についてフィルタリング又は検索するために使用するデータキューブのデータ次元以外の用量命令記録に関するデータなど）が含まれていてよい。すなわち、用量命令記録には、当該用量命令情報が用量命令記録のために用量命令ログにアクセスするためのリンクを取得するのに使用するデータキューブに含まれる次元を備えていなくても、用量命令ログに関する任意の又は全ての情報が含まれる。アプリケーションにおいて、コンプライアンス追跡データキューブにリンクされる用量命令ログは、規制コンプライアンスを決定する際に使用する政府規制局などの機関が指定した特定の形式及び／又はデータ内容を有する用量命令ログに対応することができる。

加えて、複数のデータキューブクラス定義をユーザログに関連付けることができる。例としては、ウェブセッション関連データ、ワークステーションセッション関連データ、中央ユーザセッション関連データ及び中央ユーザナビゲーション関連データ及び監査ログが含まれていてよい。ウェブセッション情報のためのデータキュークラス定義には、例えば、ユーザのＩＰアドレス、ログイン日／時間、ログアウト日／時間、ブラウザ名、ブラウザバージョン、ブラウザ拡張インストールバージョン、セッションの長さ、サイト構成時間と用量調製機能時間との間の内訳表示、ウェブサービスリクエストに対するサーバからの平均応答時間及びウェブページリクエストに対する平均応答時間を含めたウェブベースのユーザセッションに関連する情報に対応するデータ次元が含まれていてよい。ワークステーションセッションに関連するデータキューブクラス定義には、ワークステーションのログイン日／時間、ワークステーションのログアウト日／時間、ワークステーションソフトウェアバージョン、ワークステーション名、ワークステーション場所、ワークステーションにアクセスしているユーザ名及び最後のアクティビティの日／時間に関連するデータ次元が含まれていてよい。中央ユーザセッションに関連するデータキューブクラス定義には、中央セッションログ、セッショントータル時間及びブラウザタイプ／バージョンに対応するデータ次元が含まれていてよい。中央ユーザナビゲーションに関連するキュークラス定義は、中央ナビゲーションログに基づくことができる。監査ログデータクラス定義は、監査ログの完全なスナップショットを比較して、どのフィールドが変更されたかを識別するように動作可能である。

用量命令情報に存在するデータ次元の様々なものを活用することのできる他のデータキューブクラス定義を制限することなく設けることができる。更に、データキューブクラス定義に対するソースデータは、用量命令データを超えて拡大することができる。例えば、追加のデータソース（例えば、病院情報システム、薬局情報システム、研究所、手術データリポジトリ、処方記録、国家医療データベースなどに位置するもの）は、データ分析ツールによってアクセス可能である。これに関して、当該データソースを参照するデータキューブクラス定義を設けることができる。加えて、データキューブクラス定義を複数のデータソース（例えば、用量命令データ並びに病院情報システム、薬局情報システム、研究所、手術データリポジトリ及び国家医療データベースといった上述した他のデータソースを含む）を参照するデータキューブを構築するのに使用するために設けることができる。いずれの点においても、前述のデータキューブクラス定義を対応するデータキューブの構築に使用することができる。これに関して、データをユーザに提示するためにデータキューブを参照する１つ以上のレポートを生成することができる。レポートは、ピボットテーブル、ダッシュボード、チャート、グラフ、又は他のレポート構造の形式を取ることができる。レポートは、例えば、用量命令タイプ、日付、用量状態、技術者、薬剤師又はデータキューブに含まれ且つレポートに関連して定義された他のデータ次元といった様々な異なるデータ次元に基づいてフィルタリング可能であってよい（例えば、それは適切なロールと責務を有するユーザが修正可能であってよい）。更に、レポートには、上記次元レベルに基づくドリルダウンが含まれ、所定の次元データのサブセットに基づいてより詳細なデータを提供することができる。これに関して、ユーザはレポートを利用して、データキューブに基づいて生成される動的レポートに提示されたデータから傾向、異常、パターン又は他の情報を識別することができる場合がある。

本発明を図面及び上述の説明において詳細に図示及び説明してきたが、そのような図示及び説明は例示的なものであり、特徴を限定するものではないとみなすべきである。例えば、上記特定の実施形態は、説明した他の実施形態と組み合わせ可能であり、及び／又は他の方法で構成されてもよい（例えば、プロセス要素が他の順序で実行されてよい）。従って、好ましい実施形態及びその変形を示し且つ説明してきたに過ぎず、本発明の趣旨に含まれるあらゆる改変及び変更が保護されることが望ましいと理解すべきである。

Claims (65)

1. 多次元データセットの用量命令記録のサブセットに関するデータ分析をユーザに提供するのに使用する前記用量命令記録に対応する前記多次元データセットを処理するためのデータ分析ツールへの選択的なアクセスをユーザに提供する方法であって、該方法は
   複数の用量命令記録に対応する情報を備える多次元データセットを格納し、ここで前記多次元データセットの複数の用量命令記録は前記用量命令記録に対応する施設の少なくとも１つの表示を含み、前記多次元データセットは複数の施設に対応する用量命令記録を含み、
   前記複数の施設の１つでのユーザからのユーザ情報を受信し、ここで前記ユーザ情報はユーザがデータ分析ツールにアクセスしている所定の施設を表示する情報であり、
   前記データ分析ツールが前記多次元データセットにアクセスして、前記ユーザが前記データ分析ツールにアクセスしている前記所定の施設に対応する前記多次元データセットのサブセットに関する動的に生成されるレポートを生成し、及び
   前記ユーザが前記データ分析ツールにアクセスしている前記所定の施設に対応する前記多次元データセットのサブセットに関する動的に生成されるレポートを前記ユーザにユーザインタフェースで提示すること
   を含む、方法。
2. 前記データ分析ツールは、前記動的に生成されるレポートを生成するために前記多次元データセットに適用可能な複数のデータキューブクラス定義を備える、請求項１に記載の方法。
3. 前記複数のデータキューブクラス定義は、前記複数のデータキューブクラス定義の他の全てが従属する基本キューブクラス定義を備える、請求項２に記載の方法。
4. 前記基本キューブクラス定義は、前記用量命令記録に対応する施設の前記少なくとも１つの表示に関連する少なくとも１つのデータ次元を含む、請求項３に記載の方法。
5. 前記ユーザが前記データ分析ツールにアクセスしている前記所定の施設を表示する前記ユーザ情報に基づいて、前記多次元データセットに前記基本キューブクラス定義を適用し、
   前記ユーザが前記データ分析ツールにアクセスしている前記所定の施設に対応する前記多次元データセットのサブセットにユーザがアクセス可能なデータを制限するデータキューブを前記適用に基づいて構築すること
   を更に含む、請求項４に記載の方法。
6. 前記構築することは、
   前記多次元データセットのサブセットにおいて少なくとも１つのデータ変換操作を実行することを更に含み、ここで、前記少なくとも１つのデータ変換操作は前記基本キューブクラス定義で定義される、請求項５に記載の方法。
7. 前記少なくとも１つのデータ変換は、前記サブセットにおける各所定の用量命令記録の第１のデータフィールドを、前記サブセットの前記用量命令記録のそれぞれの第２のデータフィールドで自動的に書き換えることを含む、請求項６に記載の方法。
8. 前記少なくとも１つのデータ変換を用量命令記録の所定のタイプのみに適用する、請求項７に記載の方法。
9. 前記用量命令記録のタイプは、完全腸管外口栄養（ＴＰＮ）用量であり、前記第１のデータフィールドは用量説明フィールドを備え、前記第２のフィールドは前記所定の用量の薬品名フィールドを備える、請求項８に記載の方法。
10. 前記ユーザが前記データ分析ツールにアクセスしている前記所定の施設に対応する前記多次元データセットのサブセットに適用するために前記基本キューブクラス定義から従属する他のデータキューブクラス定義を呼び出し、前記多次元データセットのサブセットに関する前記動的に生成されるレポートを生成すること
    を更に含む、請求項５に記載の方法。
11. 前記複数のデータキューブクラス定義は、前記データキューブクラス定義を使用して構築されたデータキューブが保護対象保健情報（ＰＨＩ）を含むかどうかを表示するパラメータを含む、請求項３に記載の方法。
12. 前記パラメータを前記データキューブクラス定義の少なくとも１つの次元に基づいて動的に生成する、請求項１１に記載の方法。
13. 前記受信することは、
    前記ユーザが前記データ分析ツールにアクセスしている前記施設で常駐するローカルサーバでログイン情報を受信してユーザセッションを開始し、
    前記ローカルサーバで受信した前記ログイン情報に基づいて、前記ユーザを中央サーバに対して認証し、及び
    認証されたユーザログイン情報に基づいて前記ユーザセッションに関連するセッション変数を追加すること
    を更に含み、
    前記セッション変数は、前記ユーザが前記データ分析ツールにアクセスしている前記所定の施設を示す前記ユーザ情報を備える、請求項１に記載の方法。
14. 前記セッション変数に少なくとも部分的に基づいてトークンを前記データ分析ツールに渡すことを更に含み、前記トークンを中央サーバで利用可能なトークンと比較して、前記ユーザが前記データ分析ツールへのアクセスを許可されるべきかどうかを決定する、請求項１３に記載の方法。
15. 前記トークンが前記利用可能なトークンの１つと一致すると、前記トークンを前記ユーザに発行し、対応する前記利用可能なトークンを前記中央サーバから除去する、請求項１４に記載の方法。
16. 前記セッション変数は、前記ユーザが受信する前記ログイン情報に少なくとも部分的に基づいて生成される前記ユーザのロール定義を含む、請求項１３に記載の方法。
17. 前記ロール定義には、レポートの閲覧、レポートの編集、キューブクラス定義の閲覧、キューブクラス定義の編集、ピボットテーブルの閲覧、ピボットテーブルの編集、ダッシュボードの閲覧及びダッシュボードの編集に関連する前記ユーザの能力に関する表示が含まれる、請求項１６に記載の方法。
18. 前記ユーザによる前記データ分析ツールの使用に関連してユーザアクティビティをロギング（記録）することを更に含む、請求項１に記載の方法。
19. 前記ロギングすることは、前記ユーザと前記ユーザによる前記データ分析ツールの使用とに関する情報を記録することを含む、請求項１８に記載の方法。
20. 前記ロギングすることは、前記ユーザに提示される前記動的に生成されたレポートの識別を記録することを含む、請求項１９に記載の方法。
21. 前記ロギングすることは、前記ユーザに提示される前記動的に生成されたレポートが保護対象保健情報（ＰＨＩ）を含んでいたかどうかを記録することを含む、請求項２０に記載の方法。
22. 前記多次元データセットが、用量の識別、前記用量の調製工程に関するデータ、用量のタイミングに関するデータ、用量調製中に生じたエラーに関するデータ、製品の廃棄に関するデータ、薬品使用に関するデータ、投与された薬物療法に関するデータ、薬物相互作用に関するデータ及び薬局ワークフロー管理アプリケーションでのアラートに対応するデータに関するデータを備える、請求項１に記載の方法。
23. 多次元データセットの用量命令記録のサブセットに関するデータ分析のための用量命令記録に対応する多次元データセットを処理するためのデータ分析ツールを実装するためのシステムであって、
    複数のローカルサーバと動作可能に通信する中央サーバであって、各ローカルサーバは患者に投与するための用量命令に対応する用量を調製するそれぞれの対応施設に配置されており、前記ローカルサーバから前記用量命令に対応する用量命令記録に関する情報を受信する中央サーバと、
    前記複数のローカルサーバから受信する複数の用量命令記録を含む多次元データセットを備えるデータ構造を格納する中央サーバにあるデータベースであって、前記多次元データセットの前記複数の用量命令記録のそれぞれが前記用量命令記録の受信元の施設の少なくとも１つの表示を含むデータベースと、
    前記複数の施設の１つのユーザからのユーザ情報を前記複数のローカルサーバの少なくとも１つから受信するための前記複数のローカルサーバと動作可能に通信するローカルサーバインタフェースであって、前記ユーザ情報はユーザがデータ分析ツールにアクセスしている所定の施設を表示する情報であるローカルサーバインタフェースと、
    データ分析ツールとの動作可能な通信を促進するデータ分析インタフェースであって、前記データベースに格納される多次元データセットへのデータ分析ツールアクセスを提供して、前記ローカルサーバインタフェースから受信する前記ユーザ情報に基づいて前記ユーザが前記データ分析ツールにアクセスしている前記所定の施設に対応する前記多次元データセットのサブセットに関する動的に生成されるレポートを生成するデータ分析インタフェースと、
    前記ユーザが前記データ分析ツールにアクセスしている前記所定の施設に対応する前記多次元データセットのサブセットに関する前記動的に生成されるレポートをユーザインタフェースで前記ユーザに提示するユーザインタフェースと
    を備える、システム。
24. 前記データ分析ツールは、前記動的に生成されるレポートを生成するために前記多次元データセットに適用可能な複数のデータキューブクラス定義を備える、請求項２３に記載のシステム。
25. 前記複数のデータキューブクラス定義は、前記複数のデータキューブクラス定義の他の全てが従属する基本キューブクラス定義を備える、請求項２４に記載のシステム。
26. 前記基本キューブクラス定義は、前記用量命令記録に対応する施設の前記少なくとも１つの表示に関連する少なくとも１つのデータ次元を含む、請求項２５に記載のシステム。
27. 前記中央サーバと動作可能に通信するデータ分析サーバ上で実行され、前記ユーザが前記データ分析ツールにアクセスしている所定の施設を表示する前記ユーザ情報に基づいて前記多次元データセットに前記基本キューブクラス定義を適用するためのデータ分析ツールを更に含み、ここで前記データ分析ツールは前記ユーザが前記データ分析ツールにアクセスしている前記所定の施設に対応する前記多次元データセットのサブセットにユーザがアクセス可能なデータを制限するデータキューブを前記適用に基づいて構築するように動作する、請求項２６に記載のシステム。
28. 前記データ分析ツールは、前記多次元データセットのサブセットにおいて少なくとも１つのデータ変換操作を実行するように更に動作し、ここで前記少なくとも１つのデータ変換操作は、前記基本キューブクラス定義で定義される、請求項２７に記載のシステム。
29. 前記少なくとも１つのデータ変換は、前記サブセットにおける各所定の用量命令記録の第１のデータフィールドを、前記サブセットの前記用量命令記録のそれぞれの第２のデータフィールドで自動的に書き換えることを含む、請求項２８に記載のシステム。
30. 前記少なくとも１つのデータ変換を、用量命令記録の所定のタイプのみに適用する、請求項２９に記載のシステム。
31. 前記用量命令記録のタイプは、完全腸管外栄養（ＴＰＮ）用量であり、前記第１のデータフィールドは用量説明フィールドを備え、前記第２のフィールドは前記所定の用量の薬品名フィールドを備える、請求項３０に記載のシステム。
32. 前記中央サーバは、前記ユーザが前記データ分析ツールにアクセスしている前記所定の施設に対応する前記多次元データセットのサブセットに適用するために前記基本キューブクラス定義から従属する他のデータキューブクラス定義を呼び出し、前記多次元データセットのサブセットに関する前記動的に生成されるレポートを生成するように更に動作する、請求項２７に記載のシステム。
33. 前記複数のデータキューブクラス定義は、前記データキューブクラス定義を使用して構築されたデータキューブが保護対象保健情報（ＰＨＩ）を含むかどうかを表示するパラメータを含む、請求項２５に記載のシステム。
34. 前記パラメータは、前記データキューブクラス定義の少なくとも１つの次元に基づいて動的に生成される、請求項３３に記載のシステム。
35. 前記ローカルサーバは、前記データ分析ツールにアクセスしている前記ユーザからログイン情報を受信してユーザセッションを開始するよう動作し、ここで前記ローカルサーバは前記ローカルサーバで受信された前記ログイン情報に基づいて前記ユーザを中央サーバに対して認証するよう前記中央サーバと通信するように動作し、前記中央サーバは認証されたユーザログイン情報に基づいて前記ユーザセッションに関連するセッション変数を追加するよう操作し、前記セッション変数は、前記ユーザが前記データ分析ツールにアクセスしている前記所定の施設を表示する前記ユーザ情報を含む、請求項２３に記載のシステム。
36. 前記データ分析ツールは、前記サーバにアクセスしようと試みるユーザからトークンを受信するよう動作する暗号化サービスを更に備え、ここで前記トークンは前記中央サーバによって追加される前記セッション変数に少なくとも部分的に基づき、前記暗号化サービスは前記トークンを中央サーバで利用可能なトークンと比較して、前記ユーザが前記データ分析ツールへのアクセスを許可されるべきかどうかを決定するよう動作する、請求項３５に記載のシステム。
37. 前記トークンが前記利用可能なトークンの１つと一致すると、前記トークンを前記ユーザに発行し、対応する前記利用可能なトークンを前記中央サーバから除去する、請求項３６に記載のシステム。
38. 前記セッション変数は、前記ユーザが受信する前記ログイン情報に少なくとも部分的に基づいて生成される前記ユーザのロール定義を含む、請求項２５に記載のシステム。
39. 前記ロール定義には、レポートの閲覧、レポートの編集、キューブクラス定義の閲覧、キューブクラス定義の編集、ピボットテーブルの閲覧、ピボットテーブルの編集、ダッシュボードの閲覧及びダッシュボードの編集に関連する前記ユーザの能力に関する表示が含まれる、請求項３８に記載のシステム。
40. 前記ユーザによる前記データ分析ツールの使用に関連してユーザアクティビティをロギング（記録）するよう操作するロギングモジュールを更に備える、請求項２３に記載のシステム。
41. 前記ロギングすることは、前記ユーザと前記ユーザによる前記データ分析ツールの使用とに関する情報を記録することを含む、請求項４０に記載のシステム。
42. 前記ロギングすることは、前記ユーザに提示される前記動的に生成されたレポートの識別を記録することを含む、請求項４１に記載のシステム。
43. 前記ロギングすることは、前記ユーザに提示される前記動的に生成されたレポートが保護対象保健情報（ＰＨＩ）を含んでいたかどうかを記録することを含む、請求項４２に記載のシステム。
44. 前記多次元データセットが、用量の識別、前記用量の調製工程に関するデータ、用量のタイミングに関するデータ、用量調製中に生じたエラーに関するデータ、製品の廃棄に関するデータ、薬品使用に関するデータ、投与された薬物療法に関するデータ、薬物相互作用に関するデータ及び薬局ワークフロー管理アプリケーションでのアラートに対応するデータに関するデータを備える、請求項２３に記載のシステム。
45. 多次元データセットの用量命令記録のサブセットに関するデータ分析をユーザに提供するのに使用する前記用量命令記録に対応する前記多次元データセットを処理するためのデータ分析ツールへの選択的なアクセスをユーザに提供するシステムであって、
    複数のローカルサーバと動作可能に通信する中央サーバであって、各ローカルサーバは患者に投与するための用量命令に対応する用量を調製するそれぞれの対応施設に配置されており、前記ローカルサーバから前記用量命令に対応する用量命令記録に関する情報を受信する中央サーバと、
    前記複数のローカルサーバから受信する複数の用量命令記録を含む多次元データセットを備えるデータ構造を格納する中央サーバにあるデータベースであって、前記多次元データセットの前記複数の用量命令記録のそれぞれが前記用量命令記録の受信元の施設の少なくとも１つの表示を含むデータベースと、
    前記複数の施設の１つの前記ユーザからのユーザ情報を前記複数のローカルサーバの少なくとも１つから受信するための前記複数のローカルサーバと動作可能に通信するローカルサーバインタフェースであって、前記ユーザ情報はユーザがデータ分析ツールにアクセスしている所定の施設を表示する情報であるローカルサーバインタフェースと、
    前記データベースに格納される前記多次元データセットにアクセスするために前記データベースに動作可能と通信し、前記ローカルサーバインタフェースから受信する前記ユーザ情報に基づいて前記ユーザがデータ分析ツールにアクセスしている前記所定の施設に対応する前記多次元データセットのサブセットに関する動的に生成されるレポートを生成するデータ分析ツールと、
    前記ユーザが前記データ分析ツールにアクセスしている前記所定の施設に対応する前記多次元データセットのサブセットに関する前記動的に生成されるレポートをユーザインタフェースで前記ユーザに提示するユーザインタフェースと
    を備える、システム。
46. 前記データ分析ツールは、前記動的に生成されるレポートを生成するために前記多次元データセットに適用可能な複数のデータキューブクラス定義を備える、請求項４５に記載のシステム。
47. 前記複数のデータキューブクラス定義は、前記複数のデータキューブクラス定義の他の全てが従属する基本キューブクラス定義を備える、請求項４６に記載のシステム。
48. 前記基本キューブクラス定義は、前記用量命令記録に対応する施設の前記少なくとも１つの表示に関連する少なくとも１つのデータ次元を含む、請求項４７に記載のシステム。
49. 前記データ分析ツールは、前記多次元データセットのサブセットにおいて少なくとも１つのデータ変換操作を実行するように更に動作し、ここで前記少なくとも１つのデータ変換操作は、前記基本キューブクラス定義で定義される、請求項４８に記載のシステム。
50. 前記少なくとも１つのデータ変換は、前記サブセットにおける各所定の用量命令記録の第１のデータフィールドを、前記サブセットの前記用量命令記録のそれぞれの第２のデータフィールドで自動的に書き換えることを含む、請求項４９に記載のシステム。
51. 前記少なくとも１つのデータ変換を、用量命令記録の所定のタイプのみに適用する、請求項５０に記載のシステム。
52. 前記用量命令記録のタイプは、完全腸管外栄養（ＴＰＮ）用量であり、前記第１のデータフィールドは用量説明フィールドを備え、前記第２のフィールドは前記所定の用量の薬品名フィールドを備える、請求項５１に記載のシステム。
53. 前記中央サーバは、前記ユーザが前記データ分析ツールにアクセスしている前記所定の施設に対応する前記多次元データセットのサブセットに適用するために前記基本キューブクラス定義から従属する他のデータキューブクラス定義を呼び出し、前記多次元データセットのサブセットに関する前記動的に生成されるレポートを生成するよう更に動作する、請求項４９に記載のシステム。
54. 前記複数のデータキューブクラス定義は、前記データキューブクラス定義を使用して構築されたデータキューブが保護対象保健情報（ＰＨＩ）を含むかどうかを示すパラメータを含む、請求項５３に記載のシステム。
55. 前記パラメータは、前記データキューブクラス定義の少なくとも１つの次元に基づいて動的に生成される、請求項５４に記載のシステム。
56. 前記ローカルサーバは、前記データ分析ツールにアクセスしている前記ユーザからログイン情報を受信してユーザセッションを開始するよう動作し、ここで前記ローカルサーバは前記ローカルサーバで受信された前記ログイン情報に基づいて前記ユーザを中央サーバに対して認証するよう前記中央サーバと通信するように動作し、前記中央サーバは認証されたユーザログイン情報に基づいて前記ユーザセッションに関連するセッション変数を追加するよう操作し、前記セッション変数は、前記ユーザが前記データ分析ツールにアクセスしている前記所定の施設を表示する前記ユーザ情報を含む、請求項４５に記載のシステム。
57. 前記データ分析ツールは、前記サーバにアクセスしようと試みるユーザからトークンを受信するよう操作する暗号化サービスを更に備え、ここで前記トークンは前記中央サーバによって追加される前記セッション変数に少なくとも部分的に基づき、前記暗号化サービスは前記トークンを中央サーバで利用可能なトークンと比較して、前記ユーザが前記データ分析ツールへのアクセスを許可されるべきかどうかを決定するよう操作する、請求項５６に記載のシステム。
58. 前記トークンが前記利用可能なトークンの１つと一致すると、前記トークンを前記ユーザに発行し、対応する前記利用可能なトークンを前記中央サーバから除去する、請求項５７に記載のシステム。
59. 前記セッション変数は、前記ユーザが受信する前記ログイン情報に少なくとも部分的に基づいて生成される前記ユーザのロール定義を含む、請求項５６に記載のシステム。
60. 前記ロール定義には、レポートの閲覧、レポートの編集、キューブクラス定義の閲覧、キューブクラス定義の編集、ピボットテーブルの閲覧、ピボットテーブルの編集、ダッシュボードの閲覧及びダッシュボードの編集に関連する前記ユーザの能力に関する表示が含まれる、請求項４９に記載のシステム。
61. 前記ユーザによる前記データ分析ツールの使用に関連してユーザアクティビティをロギング（記録）するよう操作するロギングモジュールを更に備える、請求項４５に記載のシステム。
62. 前記ロギングすることは、前記ユーザと前記ユーザによる前記データ分析ツールの使用とに関する情報を記録することを含む、請求項６１に記載のシステム。
63. 前記ロギングすることは、前記ユーザに提示される前記動的に生成されたレポートの識別を記録することを含む、請求項６２に記載のシステム。
64. 前記ロギングすることは、前記ユーザに提示される前記動的に生成されたレポートが保護対象保健情報（ＰＨＩ）を含んでいたかどうかを記録することを含む、請求項６３に記載のシステム。
65. 前記多次元データセットが、用量の識別、前記用量の調製工程に関するデータ、用量のタイミングに関するデータ、用量調製中に生じたエラーに関するデータ、製品の廃棄に関するデータ、薬品使用に関するデータ、投与された薬物療法に関するデータ、薬物相互作用に関するデータ及び薬局ワークフロー管理アプリケーションでのアラートに対応するデータに関するデータを含む、請求項４５に記載のシステム。

Images