JP6328768B2 - メタデータ自動化システム - Google Patents

Description

本発明の実施の形態は、一般的にコンピュータデータベースに関し、特に、定義付け、創作、変更、変換、およびポピュレーションを含むデータ構造の管理の容易化に関する。

情報の自動処理は、ビジネスに多大な利益をもたらしてきた。なぜなら、意志決定者が判断をする際のあらゆる過程で、それは有効性および効率を大いに改善してきたからだ。政府、商業的ビジネス、非営利組織を問わず全ての事業は、情報を管理する業務上の必要がある。

情報は、例えば商業的ビジネスの場合、従業員、顧客、供給業者間でおこなわれる、患者の処置、顧客の獲得、注文の入力、製品の出荷、顧客への請求、請求書の受領、従業員および仕入先への支払い、製品の発注、在庫監査、取引の記録の維持に用いられる。

出来事の自然な成り行きにおいて、情報は、各組織の内部オペレーションモデルにしたがって、ソフトウェア、コンピュータハードウェア、およびデジタルネットワークを活用して獲得され、処理され、統合される。あいにく、情報の自動処理は、利用可能で、タイムリーかつコスト対効果が高いデータの統合、標準化および報告を妨げて事業を弱体化させる多くの問題をはらんでいる。

ある従来の手法では、統合され標準化されたデータを組織全体から収集するためのエンタープライズデータウェアハウスを構築することに注目した。典型的なエンタープライズデータウェアハウスは、多くのソースから、抽出され、変換され、第３の通常形態のオペレーショナルデータストアデータベースにロードされるオペレーショナルデータを必要とする。それは、再度抽出され、変換され、スタースノーフレーク・データボルトデータベースにロードされる。データボルトデータベースは、その後データマートにロードされ、それぞれ特定の部門または機能にあてられる。

エンタープライズデータウェアハウスの形成および機能プロセスにおける各データベースは、カスタム抽出変換ロード（ＥＴＬ）関数とともに設計され、維持され、ポピュレートされなければならない。さらに、組織がリポートを生成できるようになる前に、開発利用の全段階が何らかの形で完成されなければならず、かつエンタープライズデータウェアハウスから利益を得始めなければならない。

エンタープライズデータウェアハウスが、全組織のために集中管理されている標準化データを獲得するが、これはコストが非常に高くつく。金銭的コストが天文学的になりうるため、包括的なエンタープライズデータウェアハウスの実現のために要求されるリソース（開発費）は、非常に限られた小数以外の全てにとって法外に高くなりうる。金銭的なリソースが限定要因とならない場合でも、エンタープライズデータウェアハウスを構築し実現するために要する時間は、通常年単位になる。

エンタープライズデータウェアハウスに起因するエンタープライズデータウェアハウス化の他の欠点は、要約された情報を強調する判断支援アプリケーションに集中する。これらのシステムの本質的な欠点は、顧客の身元に関する取引詳細が失われることである。エンタープライズデータウェアハウスは、顧客データの分析のようなアプリケーションに適用される場合に欠点をあらわにする。顧客データの分析は、データを顧客の活動、イベント、取引、状態その他に関連付ける判断を支援する分析である。要約された情報は、顧客の身元に関する詳細レベルの情報を通常失っており、これらのアプリケーションにおけるエンタープライズデータウェアハウスの有用性は限られる。

その他の手法には、組織のオペレーショナルデータから直接、部門別データマートを創作することに注目するものがある。部門別データマートの場合、単一の部門に関するデータを取り込むだけでよい。そのため、部門別データマートは、はるかに小さくできる。

部門別データマートは、サイズが小さいことから、一般的に構築に要する時間および金銭の観点からのリソースも少なくて済むが、これらの利益もコストが高くつく。部門別データマートは集中管理されず、質またはデータ形式の観点から整合した標準を有さない。

部門別データマートが創作された場合、標準が整合しないために組織全体で統合できない。また、各部門別データマートは包括的な計画がないまま創作され、各部門がデータマートを保有すべく投資されたリソースを合計すると、よく計画された単一のエンタープライズデータウェアハウスを創作するよりも実質的に高くなりうる。整合しない部門別データマートを維持するためのリソースは、単一のエンタープライズデータウェアハウスを維持するよりもはるかに高くつくこともある。

現在、利用可能で、タイムリーかつコスト対効果が高いデータの統合、標準化および報告を提供するという課題の包括的な解決策はない。この必要性は業界内で長らく感じられてきた。

従来の開発は、上述の全ての限定を克服するための解決策を何ら教示も提案もしてこなかった。よって、これらの限定を克服するための解決策は長らく当業者に発見されなかった。

クレームされた発明は、エンティティにリンクされ、かつモジュールにおいて共にグループ分けされた特性を定義するメタデータを有するスキーマ定義言語を活用する方法、製品、およびシステムを主題とする。スキーマ定義言語は、特性に基づいて、互いにリンクを有するモジュールとエンティティとのための物理テーブルを生成するために活用される。物理テーブルは、メタデータに整合するデータでポピュレートされることができる。

スキーマ定義言語を参照して物理テーブルの位置を特定し、かつモジュールまたはエンティティのための物理テーブルが選択された特性を含んでいるか否かを判断することができるとさらに考えられる。同じ方法で、スキーマ定義言語を参照して物理テーブルの位置を特定し、物理テーブルが選択された特性を含んでいるときのみ物理テーブルが次の選択された特性を含んでいるか否かを判断することができる。

特性が選択された特性として同じモジュール内にグループ分けされているときは、スキーマ定義言語からワンホップリンケージが特定されることができるとさらに考えられる。臨床パターンがエンティティに関連付けられた特性と一致するか否かに基づいて、エンティティは、一致コホートと不一致コホートとに分類されるとさらに考えられる。

リポートデータの定義は、モジュールに関連付けられた特性をリポートデータの定義に含んでいれば、スキーマ定義言語を参照してモジュールを含めることができるとさらに考えられる。物理テーブルは、それぞれモジュールとエンティティとに関連付けられた経年的データと非経年的データとを含むことができるとさらに考えられる。

本発明の上記特徴、利点および目的が達成され、かつ詳細に理解されることができる方法で、上記簡潔に要約された発明を、添付図面に図示された実施の形態を参照してより詳細に説明する。

なお、添付図面は、本発明の典型的な実施の形態のみを説明するものであり、発明の範囲を限定するものと考えられるべきものではない。本発明は同等に効果的な他の実施の形態を許容することがあるからである。以下に示す添付図面において、同様の参照符号は同種または対応する部分に言及することを意図している。

図１は、本発明の実施の形態に係る、例示的な分散型コンピュータシステムを表す。 図２は、本発明の実施の形態に係る、データ処理システムの例示的なブロック図を表す。 図３は、本発明の実施の形態に係る、例示的なメタデータテーブルを表す。 図４は、本発明の実施の形態に係る、例示的なスキーマ定義モデルを表す。 図５は、本発明の実施の形態に係る、例示的なスキーマ定義モデルテーブルを表す。 図６は、本発明の実施の形態に係る、例示的な物理的なスキーマテーブルを表す。 図７は、本発明の実施の形態に係る、オペレーショナルデータストアを実現し、ポピュレートするための例示的な制御フローを表す。 図８は、本発明の実施の形態に係る、抽出変換ロード関数を生成するための例示的な制御フローを表す。 図９は、本発明の実施の形態に係る、コホートのフィルタリングのための例示的な制御フローを表す。 図１０は、ビジネスインテリジェンスツールにおいて実現されるフィルタのスクリーンショットを表す。 図１１は、本発明の実施の形態に係る、パターンを活用したコホートのフィルタリングのための例示的な制御フローを表す。 図１２は、ビジネスインテリジェンスツールにおいて実現されるフィルタのスクリーンショットを表す。 図１３は、本発明の実施の形態に係る、リポートを生成するための例示的な制御フローを表す。 図１４は、ビジネスインテリジェンスツールにおいて実現されるリポートデータの定義のスクリーンショットを表す。 図１５は、本発明の実施の形態に係る、リポートを分析するための制御フローを表す。

本発明の次に説明する実施の形態において、本発明の一部を構成し、かつ本発明が実施されることがある例示的な実施の形態を説明する目的で示される添付図面を参照する。本発明の範囲から逸脱することなく、他の実施の形態も利用してもよく、構造上の変更をおこなってもよいと理解されるべきである。

次に述べる実施の形態は、当業者が本発明を実施し利用できる程度に十分詳細に説明される。他の実施の形態は、本開示に基づき明らかとなるであろうこと、また、本発明の範囲から逸脱することなく、システム、プロセス、機械的な変更をおこなってもよいことが理解されるべきである。

以下に述べる説明において、本発明の完全な理解のために数多くの具体的な詳細が与えられているが、これらの具体的な詳細なしに本発明を実施してもよいことが明らかとなる。本発明が不明瞭になるのを避けるため、いくつかの周知の回路、システム構成、プロセスステップは詳細に開示されない。

また、いくつかの特徴を共通にする複数の実施の形態が開示され説明されている部分において、説明、記載、理解を明確かつ容易にするために、互いに類似または同種の特徴は、同種の参照符号付きで通常説明される。これらの実施の形態は、説明の便宜上、第１実施形態、第２実施形態等というように番号が付されているが、他の意義があり本発明を限定するものと意図していない。

解説的な目的で、ここで用いられる「メタデータ」という語は、データについてのデータとして定義される。ここで用いられる「システム」という語は、この語が用いられるコンテキストにしたがって、本発明の方法および装置を意味し指し示す。

本発明の実施の形態は、独自のスキーマ定義言語を採用するため、かつデータベースまたはデータストアを構築し、生成し、ポピュレートする際のスキーマ定義言語を活用するための技術を提供し、スキーマ定義言語を参照して抽出−変換―ロード関数を自動的に生成し、かつデータベースまたはデータストアからデータを引き出すビジネスインテリジェンスツールを実現可能にするための技術を提供する。ここで用いられるように、ビジネスインテリジェンスツールとは一般的に、データを報告し、分析し、提示するよう構成されたソフトウェアアプリケーションを指す。このデータは、データウェアハウス、データベース、データストア、データマート、またはそれらの組み合わせにおいて格納される。

ある態様によれば、スキーマ定義言語は、スキーマ定義言語によって定義された特性、エンティティ、およびモジュールの関係を示すスキーマ定義モデルにおいて実現されることができ、またはスキーマ定義モデルによって提示されることができる。スキーマ定義言語は、オペレーショナルデータストアの物理テーブルのための構造およびフレームワークを定義する。スキーマ定義言語は、スキーマ定義モデルを物理データの１以上の物理エンティティにマッピングするための関係と位置とを含んでもよい。したがって、スキーマ定義言語は、物理データの特定のセットを含んでいる物理データのフィールドへのアクセスを定義し、アクセスするために用いられることができる。

有利なことに、本発明の実施の形態は、高い抽象化レベルでスキーマ定義言語を提供し、オペレーショナルデータストアを低コストかつ短いタイムフレームで活用するためのビジネスインテリジェンスツールを実現可能にするためのスキーマ定義言語とのインターフェースとなるプラットフォームを提供するための技術を提供する。スキーマ定義言語は、基礎となるデータベースが発展したときでも、これらのツールがもはや変更される必要がないように、高い抽象化レベルで動作するビジネスインテリジェンスツールを実現可能にする。データベースは、本発明のスキーマ定義言語を活用する際、容易にかつ妨害されることなく発展する。

有利なことに、物理テーブルにアクセスしてクエリを実行するためのスキーマ定義言語を活用するビジネスインテリジェンスツールは、前のステップで選択された特性のタイプに関連するオプションを提供することによって、ユーザに直感的な体験を提供する。スキーマ定義言語は、オペレーショナルデータストアをモデル化し設計するための容易かつ効果的な解決策を実現可能にする物理テーブルにシンプルな構造を与えるためにも用いられることができる。さらに、スキーマ定義言語を活用すると、スキーマ定義モデル内に含まれているスキーマ定義言語構造とメタデータとに基づいてオペレーショナルデータストアに素早くポピュレートするための関数を自動的に抽出し、変換し、ロードすることが可能になる。

以下において、本発明の実施の形態および具体的な例を参照するが、本発明は具体的に説明される実施の形態または実施例に限定されないと解釈されるべきである。代わりに、異なる実施の形態に関連するか否かに関わらず、以下の特徴および要素のいかなる組み合わせも、本発明を実現し実施するために考慮される。さらに、本発明の実施の形態は、他の可能な解決策を超え、かつ／または先行技術を超える有利な効果を達成することがあるが、ある実施の形態によって特定の効果が達成されるか否かは本発明を限定するものではない。よって、以下の態様、特徴、実施の形態、および有利な効果は、説明目的に過ぎず、添付された請求項において明示的に記載されている場合を除き、請求項の特徴または限定とは解釈されない。同様に、「本発明」への言及は、ここに開示されたいずれかの発明の主題を一般化するものと解釈されてはならず、添付された請求項において明示的に記載されている場合を除き、請求項の特徴または限定と解釈されてはならない。

添付された請求項のいずれかが純粋なソフトウェアおよび／またはファームウェアによる実現を権利範囲に含むように読めるときは、これによって少なくとも一つの実施例の少なくとも一つの要素は、当該ソフトウェアおよび／またはファームウェアを格納した有形のコンピュータで読み取り可能なメディアを含むことが明示的に定義される。

本発明のある実施の形態は、コンピュータシステムで用いられるプログラム製品として実現される。プログラム製品のプログラムは、実施の形態の機能（そこに記載された方法を含む）を定義し、さまざまなコンピュータで読み取り可能なストレージメディアに保存可能である。ここに定義するコンピュータで読み取り可能なストレージメディアは、製品である。説明目的であり限定されないコンピュータで読み取り可能なストレージメディアには、次にあげるものが含まれる。すなわち、（ｉ）情報が永久に格納される書き込み不可のストレージメディア（例えば、ＣＤ−ＲＯＭドライブで読み取り可能なＣＤ−ＲＯＭディスクのような、コンピュータ内の読み取り専用メモリデバイス）や、（ｉｉ）書き換え可能な情報が格納される書き込み可能なストレージメディア（例えば、ディスケットドライブまたはハードディスクドライブ内のフレキシブルディスク）である。そのようなコンピュータで読み取り可能なストレージメディアは、本発明の機能を指令するコンピュータで読み取り可能な命令を備えるときは、本発明の実施の形態である。他のメディアには、無線通信ネットワークを含むコンピュータまたは電話ネットワークなどの、情報をコンピュータに伝達する通信メディアが含まれる。後者の実施の形態は、特に、情報をインターネットおよび他のネットワークへ／から送受信することを含む。そのような通信メディアは、本発明の機能を指令するコンピュータで読み取り可能な命令を備えるときは、本発明の実施の形態である。広義には、コンピュータで読み取り可能なストレージメディアおよび通信メディアは、ここではコンピュータで読み取り可能なメディアと言及されることがある。

一般的に、本発明の実施の形態を実現するために実行されるルーティンは、オペレーションシステムまたは特定のアプリケーション、部品、プログラム、モジュール、オブジェクト、あるいは命令シーケンスの一部であってもよい。本発明のコンピュータプログラムは、典型的には、ネィティブコンピュータによって機械で読み取り可能であり実行可能な命令に翻訳されることとなる多数の命令からなる。また、プログラムは、プログラムにローカルに存在するかメモリまたはストレージメディアの中で発見される変数およびデータ構造からなる。また、以下説明されるさまざまなプログラムは、本発明の特定の実施の形態においてプログラムが実現されるためのアプリケーションに基づいて特定されてもよい。しかしながら、後に続く特定のプログラムのいかなる名称も便宜上用いられるものに過ぎないと解釈されるべきである。よって、本発明はそのような名称によって特定され、かつ／または暗示される特定のアプリケーションにおいてのみ用いられると限定されるべきではない。

ここで図１を参照すると、そこには、本発明の実施の形態に係る、例示的な分散型コンピュータシステム１００が示されている。一般的に、分散型コンピュータシステム１００は、分散された環境として示され、コンピュータシステム１０２と複数のネットワーク接続された装置１０４とを含む。コンピュータシステム１０２は、次に述べるいかなるタイプのコンピュータ、コンピュータシステム、または他のプログラム可能な電子機器を示してもよい。すなわち、本発明の方法、装置、および製品に対応するよう適応させたクライアントコンピュータ、サーバーコンピュータ、ポータブルコンピュータ、組み込みコントローラ、ＰＣベースのサーバー、ミニコンピュータ、ミッドレンジコンピュータ、メインフレームコンピュータ、および他のコンピュータなどである。

説明目的で、コンピュータシステム１０２は、ネットワーク接続されたシステムからなる。しかしながら、コンピュータシステム１０２は、独立した装置からなってもよい。いずれにせよ、図１はコンピュータシステム１００の一構成に過ぎないと理解される。本発明の実施の形態は、匹敵するいかなる構成にも適用することができる。コンピュータシステム１０２が複雑な複数ユーザ用装置、単一ユーザ用ワークステーション、または自身の不揮発性ストレージを有さないネットワーク機器であるか否かを問わない。

本発明の実施の形態は、通信ネットワークを通してリンクされたリモート処理装置によってタスクが実施される分散型コンピューティング環境において実施されてもよい。分散型コンピューティング環境において、プログラムモジュールは、ローカルおよびリモート両方のメモリストレージデバイスに置かれてもよい。これに関し、コンピュータシステム１０２および／または１以上のネットワーク接続された装置１０４は、ほとんどまたはまったく処理をおこなわないシンクライアントであってもよい。

コンピュータシステム１０２は、次にあげるものに示されるような数多くのオペレータや周辺システムを含みうる。例えば、直接アクセスストレージデバイス１０８に操作可能に接続された大型ストレージインターフェース１０６、ディスプレイ１１２に操作可能に接続されたビデオインターフェース１１０、および、複数のネットワーク接続された装置１０４に操作可能に接続されたネットワークインターフェース１１４である。ディスプレイ１１２は、視ることが可能な情報を出力するためのビデオ出力装置であればよい。

コンピュータシステム１０２は、メインメモリ１２０からバス１１８を経由して命令およびデータを取得する少なくとも１つのプロセッサ１１６からなるものとして示される。プロセッサ１１６は、本発明の方法に対応するよう適応させた何らかのプロセッサでありえる。

メインメモリ１２０は、必要なプログラムおよびデータ構造を保持するには十分な大きさの何らかのメモリである。メインメモリ１２０は、ランダムアクセスメモリや不揮発性またはバックアップメモリ（例えばプログラム可能なまたはフラッシュメモリや読み取り専用メモリなど）を含む単独のメモリデバイス、またはこれらのメモリデバイスの組み合わせでありうる。また、メモリ１２０は、コンピュータシステム１０２内のどこかに物理的に位置するメモリを含んでいると考えてもよい。例えば、バーチャルメモリ、大型ストレージデバイス（例えば、直接アクセスストレージデバイス１０８）、またはコンピュータシステム１０２にバス１１８経由で接続された他のコンピュータとして用いられる記憶装置であればよい。

メモリ１２０は、オペレーティングシステム１２２と構成されるものとして示される。オペレーティングシステム１２２は、コンピュータシステム１０２のオペレーションを管理するために用いられるソフトウェアである。

メモリ１２０はさらに、アクセス層１２４と、スキーマ定義言語１２６と、フィルタ１２８と、リポートデータの定義１３０と、１以上のアプリケーション１３２と、複数のビジネスインテリジェンスツール１３４とをさらに備える。アプリケーション１３２、ビジネスインテリジェンスツール１３４、およびアクセス層１２４は、コンピュータシステム１０２におけるさまざまなメモリおよびストレージ装置においてさまざまなときに存在する複数の命令からなるソフトウェア製品である。コンピュータシステム１０２において１以上のプロセッサ１１６によって読み取られ実行されるとき、アプリケーション１３２、アクセス層１２４、およびスキーマ定義言語１２６は、個別にまたは組み合わせとして、コンピュータシステム１０２に本発明のさまざまな態様を実行するために必要なステップを実施させる。

アクセス層１２４（より一般的には、オペレーティングシステム１２２を含む要求するエンティティ）は、データベース１３６にクエリを発行するよう構成される。説明目的で、データベース１３６は、ストレージ１０８におけるデータベース管理システム（ＤＢＭＳ）の一部として示される。簡単のためひとつのデータベースのみ示されているが、ＤＢＭＳ１３８は複数のデータベースを含んでもよい。

さらに、これらのデータベースは互いに分散されてもよい。さらに、１以上のデータベースは、１以上のネットワーク接続された装置１０４に分散されることができる。説明目的で、ネットワーク接続されたシステム１４０は、データベース１４４を含むＤＢＭＳ１４２を備えるものとして示される。簡単のためひとつのデータベース１４４のみ示されるが、ＤＢＭＳ１４２は複数のデータベースを含んでもよい。さらに、これらのデータベース１４２は互いに分散されてもよい。このような異なる実施態様の全てが広く考慮される。ストレージ１０８またはネットワーク接続された装置１０４は、フィルタを構成するため、ユーザにフィードバックするため、およびビジネスインテリジェンスツール１３４のためのリポートデータの定義を構成するためのアプリケーション１３２によって用いられる、メタデータテーブル、物理テーブル、スキーマ定義言語１２６、またはスキーマ定義モデルをも含んでもよい。

データベース１３６および１４４は、データの特定の物理表現に関わらずデータの集合の代表的なものである。データの物理的な表現は、当該データの構造上のスキーマを定義する。

ある実施の形態において、データベース１３６はオペレーショナルデータベースを含んでおり、データベース１４４はオペレーショナルデータストアを含んでいる。オペレーショナルデータベースは、データストア内に含まれる物理データの少なくとも一部を含んでいる。ある態様によれば、データストアは、オペレーショナルデータベースにおける物理データから導出されるクエリを実行可能なデータを含んでいる。したがって、データストアにおけるクエリを実行可能なデータは、オペレーショナルデータベースにおける物理データのサブセットを含んでいる。オペレーショナルデータベースからのデータのサブセットに加え、データストアは他のデータを含んでもよい。

ある実施の形態において、クエリは、入力（例えばユーザ入力）に応答して生成されてもよい。クエリは、スキーマ定義言語１２６に定義された論理フィールドを用いて構成されることができる。クエリは、データベース１４４内の物理データによって表される図４のエンティティ４０４のクラスを分離するか定義するためのスキーマ定義言語１２６を参照することができるフィルタ１２８を用いて、データベース１４４に対して実行される。フィルタ１２８のオペレーションは、図９〜１２を参照して以下に詳細に説明される。

クエリは、図４のスキーマ定義言語、エンティティ４０４の構造リポート、モジュール４０６、および特性の観察（オブザベーション）４０８を参照可能なリポートデータの定義１３０を用いてデータベース１４４に対しても実行され、データベース１４４内の物理テーブルからデータを引き出す。リポートデータの定義１３０のオペレーションは、図１３〜１５を参照して以下に詳細に説明される。

ここで図２を参照すると、そこには、本発明の実施の形態に係る、データ処理システム２００の例示的なブロック図が示されている。データ処理システム２００はデータ入力ブロック２０２を含み、データ入力ブロック２０２は１以上の外部ソース２０４からデータ２０３を抽出して接続しているオペレーショナルデータストア２０６にロードするためのものである。例えば、外部ソース２０４は、図１のストレージデバイス１０８のデータベース１３６でありえる。オペレーショナルデータストア２０６は、図１のネットワーク接続された装置１０４のデータベース１４４内に含まれうる。

管理エンジン２０８は、オペレーショナルデータストア２０６におけるデータ２０３の少なくとも一部をマッピングし位置を特定するよう構成され、後に続くアロケーション処理、マッピング、フィルタリング、リポーティングなどのためにスキーマ定義言語１２６に基づいてデータ２０３の位置と関係とを計算する。

データ処理システム２００は、ユーザにデータ２０３を伝達するために、情報伝達ブロック２１０をも備え、オペレーショナルデータストア２０６および管理エンジン２０８に接続されている。伝達機能は、ビジネスインテリジェンスツール１３４によって実施されることができる。ビジネスインテリジェンスツール１３４は、図９および１１においてそれぞれ説明されたトランスメッドシステム・コホート・エクスプローラまたはトランスメッドシステム・臨床パターンマッチャーのようなフィルタリングツールでありえる。ビジネスインテリジェンスツール１３４は、図１３および１５においてそれぞれ説明されたトランスメッドシステム・コホート・リポーターまたはトランスメッドシステム・コホート・アナライザーのようなリポーティングツールでありえる。

また、データ処理システム２００の情報伝達ブロック２１０は、ユーザから実行時パラメータを受信するためのユーザインターフェース２１２と、ユーザインターフェース２１２からの入力に応答して管理エンジン２０８を起動するためのタスクコントローラ２１４とを備える。ユーザインターフェース２１２は、ユーザとの双方向通信のためのハードウェアおよびソフトウェアを備えうる。タスクコントローラ２１４は、ユーザインターフェース２１２を介したデータ２０３のグルーピング、フィルタリング、リターンニングのためのパラメータと命令とをユーザが提出できるようにする管理エンジン２０８とも通信する。

データ入力ブロック２０２は、１以上の外部ソース２０４からデータ２０３を抽出するための抽出−変換−ロード（ＥＴＬ）ツール２１６を用い、その後抽出されたデータ２０３を少なくともひとつの望ましいデータ形式に変換する。変換されたデータ２０３は、その後データの格納のためにオペレーショナルデータストア２０６において１以上の物理テーブル２１８へロードされることができる。

重要なことに、管理エンジン２０８は、ビジネスインテリジェンスツール１３４および物理テーブル２１８のためのフレームワークとしてスキーマ定義言語１２６を提供することができる。管理エンジン２０８は、スキーマ定義言語１２６を活用して外部ソース２０４からデータ２０３内の物理テーブル２１８をポピュレートするためのＥＴＬツール２１６を自動的に生成することができる。

ＥＴＬツール２１６を自動化し物理テーブル２１８をポピュレートするオペレーションについては、図７および８に関して以下に説明する。管理エンジン２０８はさらに、ビジネスインテリジェンスツール１３４がリポートとフィルタ検索とを構造化するために動作可能となるフレームワークとして、スキーマ定義言語１２６を提供する。

スキーマ定義言語１２６は、エンティティタイプ２２０と、特性２２２と、モジュールタイプ２２４とを含む。特性２２２は、リンク２２６を有するエンティティタイプ２２０にリンクされる。特性２２２は、特性２２２が共に観察されるか否かに基づいて、モジュールタイプ２２４において共にグループ分けされることができる。

エンティティタイプ２２０、特性２２２、およびモジュールタイプ２２４は、オペレーショナルデータストア２０６において物理テーブル２１８の構造と関係とを提供する図４に関して以下のように説明されるスキーマ定義モデル４００の構造とフォーメーションを提供するスキーマ定義言語１２６のメタデータ構造でありえる。スキーマ定義言語１２６はさらに、データ２０３がどのようにして物理テーブル２１８にポピュレートすることとなるかについてのフレームワークをさらに提供する。

説明目的と理解を容易にするために、エンティティタイプ２２０、特性２２２、およびモジュールタイプ２２４について、ヘルスケア分野を参照して以下説明する。当業者であれば、説明目的のためにそのようにされ、本発明を限定することを意図しないことを認識するであろう。

エンティティタイプ２２０は物理オブジェクトのタイプを定義することができると考えられる。図４の実際のエンティティ４０４のエンティティタイプ２２０は、データ構造であるアブストラクションおよび図３のメタデータ３０２である。実際のエンティティ４０４は、図４の特性の観察４０８とライフタイムを有するエンティティタイプ２２０の具体的な例である。ここで用いられるライフタイムは、妥当なオブザーバがエンティティタイプ２２０の一つとして物理オブジェクトを認識するであろう状態において物理オブジェクトが存在するタイムスパンとして定義される。ここで特性の観察４０８は、エンティティ４０４について観察可能な事実として定義される。

ヘルスケア分野に関連して、エンティティタイプ２２０は、患者、外科医、または施設として例示されることができる。エンティティ４０４は、特定の病院、患者、外科医、または支払い者として例示されることができる。つまり、エンティティ４０４は、ジョーンズ医師やサバーバン病院である。

モジュールタイプ２２４は、特性の観察４０８の観察結果となる特定のレコードやモーメントを定義することができると考えられる。モジュールタイプ２２４は、データ構造である、図４の実際のモジュール４０６のアブストラクションおよびメタデータ３０２である。実際のモジュール４０６は、モジュールタイプ２２４の具体的な例である。モジュール４０６は、通常共に観察されるエンティティ４０４のために観察される特性の観察４０８をリスト化することができる。ここで用いられるように、モジュール４０６は、しばしば共に観察されるエンティティ４０４の関連した特性の観察４０８の集合として定義される。モジュールタイプ２２４は、特性２２２の観察の開始および終了日程を含むことができる。モジュールタイプ２２４は、モジュールタイプ２２４と関連付けられた特性２２２をリスト化し、モジュールタイプ２２４の開始および終了日程を特定する。モジュールタイプ２２４は、期間のないイベントの開始および終了タイムスタンプと同じ単一の日または時間のスタンプのみを含むことができるとさらに考えられる。

モジュールタイプ２２４は、入院（入院日、退院日）、診断（診断日）、処置（処置開始日および終了日）、病理検査（病理検査日）として例示されることができる。モジュール４０６それ自身は、特定の入院、診断、処置、および病理検査として例示されることができる。つまり、モジュール４０６は、２０１２年２月５日にサバーバン病院の緊急処置室に受け入れられたマイク・ジョンソンでありえ、マイク・ジョンソンは２０１２年２月５日に肺炎と診断され、ジョーンズ医師は、マイク・ジョンソンの肺炎を処置するために２０１２年２月５日にマイク・ジョンソンにベンジルペニシリンを投与し、またはジョーンズ医師は、２０１２年２月５日にマイク・ジョンソンのために分類なしの全血球計算を命じる。

特性２２２は、エンティティ４０４のため、またはエンティティ４０４の単一の観察可能なプロパティまたは特性の観察４０８を定義することができると考えられる。特性２２２は、名称を有し、整数、実際、日時、テキスト、選択、モジュールポインタまたはエンティティポインタのような、図４の特定のデータタイプ４１０を指定する。特性２２２は、観察された特性の観察４０８のデータ構造であるアブストラクションおよびメタデータ３０２である。特性の観察４０８は、エンティティ４０４についての事実の観察の具体的な例である。特性の観察４０８は、特性２２２のデータタイプ４１０に一致する。

特性２２２は、時間のデータタイプ４１０付きの診断日、選択のデータタイプ４１０付きのＩＣＤ９選択、テキストのデータタイプ４１０付きの外科医ノート、または選択のデータタイプ４１０付きの重症度選択としての診断モジュールタイプのために例示されることができる。特性２２２はさらに、入院モジュールのタイプとして、日時のデータタイプ４１０付きの入院日、日時のデータタイプ４１０付きの退院日、選択のデータタイプ４１０付きの主たる支払い者、または選択のデータタイプ４１０付きの退院措置として例示されることができる。

特性の観察４０８は、診断日：２０１２年２月５日午後１時３０分、ＩＣＤ９：「４８０．１」、または外科医ノート「患者は呼吸困難」として診断モジュールのために例示されることができる。特性の観察４０８は、入院モジュールとして、診断日：２０１２年２月５日午前１１時３０分、退院日：２０１２年２月７日午後１時３０分、主たる支払い者「Ａｅｔｎａ」、退院措置：「自宅」として例示されることができる。

特性２２２は、経年的および非経年的な特性の観察４０８を含むことができる。経年的な特性の観察４０８は、ここで用いられるように、エンティティ４０４の生涯に生じるものとして扱われるイベントに対応する特性の観察４０８を意味するよう定義される。経年的な特性の観察４０８は、通常、それらを所有するために観察されるエンティティ４０４の生涯よりも短い期間を有する。非経年的な特性の観察４０８は、ここで用いられるように、氏名、血液型、患者ＩＤのようなエンティティ４０４の生涯継続するものとして取り扱われる特性の観察４０８を意味するよう定義される。非経年的な特性は、変化することもあるが、特定のイベントに必ずしも関連付けられない。エンティティタイプ２２０は、エンティティ４０４の非経年的な特性を獲得するために、モジュールタイプ２２４のうちの特別なひとつを付与されることができる。一方、経年的な特性は、エンティティ４０４の発生日を付与されることとなり、標準モジュールタイプ２２４と共にグループ分けされることとなる。

メタデータ３０２として実現され、図３のメタデータテーブル３００によって表されるスキーマ定義言語１２６を活用することにより、モジュール４０６によってグループ分けされる特性の観察にリンクされたエンティティ４０４を意味論的に表すこと、それにより物理テーブル２１８のためのシンプルかつ効果的なフレームワークを提供することを発見した。このフレームワークは、メタデータテーブル３００のスキーマ定義言語１２６と結び付けられるものであるが、メタデータテーブル３００を参照することによって物理データテーブル２１８を素早く、シンプルに、かつ効果的に利用可能にする。物理データテーブル２１８は、メタデータテーブル３００においてスキーマ定義言語１２６を参照することによりリポートを生成するためにフィルタリングされ用いられることができる。

メタデータテーブル３００においてメタデータ３０２として獲得されたスキーマ定義言語１２６は、実施コストとタイムラインを同時に削減しながら直感的な方法でリポートを生成するために、物理データテーブル２１８がフィルタリングされ用いられることを可能にする。実施タイムラインは、スキーマ定義言語１２６を活用することによって大幅に削減されることができる。なぜなら、典型的なデータウェアハウスにおいて、データ構造は正規化されて次元テーブルに置かれる必要があるからである。しかしながら、スキーマ定義言語１２６を活用することによって、データ２０３はメタデータ構造およびデータ構造とシンプルに関連付けられることができる。一度関連付けられれば、ＥＴＬツール２１６は自動的に生成されることができ、物理データテーブル２１８はポピュレートされることができる。オペレーショナルデータストア２０６の物理データテーブル２１８がポピュレートされ次第、ビジネスインテリジェンスツール１３４は、追加的に複数の正規化ステップを要することなく、また、各ステップ間で抽出、変換およびロード動作を有する次元テーブルをポピュレートすることなく、スキーマ定義言語１２６を活用してオペレーショナルデータストア２０６におけるデータをフィルタリングし、リポートし、クエリを実行することができる。

予め定義されたデータタイプ４１０を有する特性２２２を提供するスキーマ定義言語１２６は、ＥＴＬツール２１６の自動生成を可能にし、これにより実施コストとタイムラインを大幅に削減することもさらに発見した。

ビジネスインテリジェンスツール１３４が効果的に動作してユーザに直感的な体験を与えることができるように、情報伝達ブロック２１０は、スキーマ定義言語１２６を参照するための管理エンジン２０８に接続される。管理エンジン２０８は、フィルタ１２８とリポートデータの定義１３０とをさらに有することができる。フィルタ１２８は、エンティティ４０４の特性の観察４０８に基づいて、エンティティ４０４のクラスを生成するために用いられる一次元フィルタでありえる。フィルタは、図９〜１２を参照して以下に詳細に説明される。リポートデータの定義１３０は、リポートのために要求され望まれる、かつオペレーショナルデータストア２０６からデータ２０３をリトリーブするために活用されることとなる、エンティティタイプ２２０と、モジュールタイプ２２４と、特性２２２とのセットでありえる。リポートデータの定義１３０は、図１３および１４を参照して以下に詳細に説明される。

ここで図３を参照すると、そこには、本発明の実施の形態に係る例示的なメタデータテーブル３００が示されている。メタデータテーブル３００は、図１のスキーマ定義言語１２６を表わす。スキーマ定義言語１２６は、図２の物理データテーブル２１８のデータ２０３を説明するためのメタデータ３０２として用いられることができる。メタデータテーブル３００間で、複数の関係リンク３０４を有することができる。メタデータテーブル３００は、特性テーブル３０８にリンクされたエンティティタイプテーブル３０６を有することができる。エンティティタイプテーブル３０６と特性テーブル３０８とは、モジュールタイプテーブル３１０にリンクされることができる。

エンティティタイプテーブル３０６と、特性テーブル３０８と、モジュールタイプテーブル３１０とは、図２のエンティティタイプ２２０と、特性２２２と、モジュールタイプ２２４とそれぞれ関連付けられることができる。メタデータテーブル３００は、エンティティタイプテーブル３０６、モジュールタイプテーブル３１０、および特性テーブル３０８内で行として、図４のエンティティ４０４、モジュール４０６、および特性の観察４０８をそれぞれ含むことができる。

メタデータテーブル３００は、物理データテーブル２１８を意味論的表現によってマッピングするメタデータ３０２を含んでいる。一例として、特性テーブル３０８は、特性の観察４０８の対応する行を含むことができる。一例として、ＩＣＤ９選択は、特性テーブル３０８内の行として含まれることができる特性の観察４０８である。特性テーブル３０８のＩＣＤ９選択は、モジュール４０６への、かつ／または特性の観察４０８に関連付けられることができるエンティティ４０４へのポインタまたはレファレンスを含むことができる。例えば、ＩＣＤ９の特性の観察４０８は、診断モジュール４０６と患者エンティティ４０４とを指し示すことがある。

メタデータテーブル３００は意味論的表現または物理データテーブル２１８の構造のマップを含むので、メタデータテーブル３００は物理データテーブル２１８内に含まれるデータ２０３の位置を特定するために用いられることができる。メタデータテーブル３００は、物理データテーブル２１８のデータ２０３間の関係リンク３０４を特定するためにも用いられる。

モジュールタイプテーブル３０６と、エンティティタイプテーブル３０６と、特性テーブル３０８との関係は、図２に関しすでに詳細に説明されたエンティティタイプ２２０と、特性２２２と、モジュールタイプ２２４との関係を示す。

メタデータテーブル３００間の関係リンク３０４は、データ２０３がどのようにして図２のオペレーショナルデータストア２０６の物理テーブル２１８内に結果的に構成されることとなるかについてのマップである。関係リンク３０４は、モジュール４０６、エンティティ４０４あるいは他のデータまたはメタデータ構造を指し示すか参照する特性の観察４０８を絵で表したものである。

スキーマ定義言語１２６の関係リンク３０４は、データ２０３を結果的に保持することとなる物理テーブル２１８のための関係構造を提供する。スキーマ定義言語１２６は、物理テーブル２１８の位置を特定するためのマップと物理テーブル間の関係とを与える。

一例として、図１のビジネスインテリジェンスツール１３４が、スキーマ定義言語１２６を参照して特性の観察４０８の位置を特定し、特性の観察４０８がどのようにしてエンティティ４０４とモジュール４０６とにリンクされているかを判断することにより、ユーザはエンティティ４０４またはモジュール４０６をフィルタリングするための特性の観察４０８を選択する。特性の観察４０８にリンクされたモジュール４０６とエンティティ４０４とがメタデータテーブル３００によって一度特定されると、他の特徴の観察４０８が、ユーザが選択した特徴の観察４０８として同じモジュール４０６またはエンティティ４０４に属する。

エンティティ４０４とモジュール４０６とについての特性の観察４０８の関係を提供することにより、図２の管理エンジン２０８は、選択された第１の特性の観察４０８に関連する他の特性の観察４０８を選択するオプションをユーザに与えることができ、または、他のモジュール４０６を選択するオプションをユーザに与えることができる。管理エンジン２０８は、ユーザのための選択オプションとして他の特性の観察４０８をユーザへ同じモジュール４０６からリターンするためのスキーマ定義言語１２６を活用することができる。このようにして、スキーマ定義言語１２６は、スキーマ定義言語１２６内に要求されたか含まれたものとして物理テーブル２１８内のデータ２０３の構造のみに基づいて、関連するフィルタまたはリポートをユーザに提供するために活用されることができる。

メタデータ３００間の関係リンク３０４は、多対１リンク３１２を示す。エンティティタイプテーブル３０６とモジュールタイプテーブル３１０とは、エンティティ４０４間で階層的な関係を可能にするリカーシブリンク３１４をも含んでいる。

他のテーブルは、データタイプテーブル３１６、選択タイプテーブル３１８、選択テーブル３２０、および承認テーブル３２２を含むメタデータテーブル３００を構成することができる。メタデータテーブル３００は、本発明から逸脱することなくより多くのテーブルを含むことができると考えられる。一例として、メタデータテーブル３００は、モジュールタイプメンバーテーブルまたは測定単位テーブルを含んでもよい。本発明から逸脱することなくテーブルは組み合わされまたは削除されることができるとさらに理解される。

ここで図４を参照すると、そこには、本発明の実施の形態に係る例示的なスキーマ定義モデル４００が示されている。スキーマ定義モデル４００は、図１のスキーマ定義言語１２６をデータコンテキストに適用することができる。説明目的のためのみのヘルスケアの例を続けると、エンティティタイプ２２０と、モジュールタイプ２２４と、特性２２２とは、エンティティ４０４と、モジュール４０６と、特性の観察４０８のためのメタデータ３０２にマッピングされた。

メタデータ３０２は、エンティティタイプ２２０と、モジュールタイプ２２４と、特性２２２と同様に、エンティティ４０４と、モジュール４０６と、特性の観察４０８とに関連付けられることができる。以下に説明的な例を通じて示されるように、スキーマ定義モデル４００内に含まれるメタデータ３０２は、特性の観察４０８がどのようにしてエンティティ４０４にリンクされるかについて、および、特性の観察４０８がどのようにしてモジュール４０６と共にグループ分けされるかについて定義することができる。

説明的な一例として、エンティティ４０４は、患者、サンプル、実験または遺伝的変種でありえる。エンティティ４０４は、共にグループ分けされた非経年的な特性の観察４０８を有するものとして示される。説明的な一例として、患者として特定されたエンティティ４０４と共にグループ分けされた特性の観察４０８は、ＩＤ、誕生日、死亡日、性別、民族性、主たる支払い者、および現在の生活機能状態を含むことができる。

モジュール４０６と共にグループ分けされた特性の観察４０８は、経年的な特性の観察４０８として示される。説明的な一例として、照射のためのメタデータ３０２を有するモジュール４０６と共にグループ分けされた特性は、１回分の追加照射、追加照射処置モダリティ、処置回数、放射線照射対象の解剖学的部位、放射線量、および局所への１回分の照射量を含むことができる。モジュール４０６は、照射に対応するモジュール４０６において処置モジュール４０６のためのポインタのような他のモジュール４０６への外来キーとなるポインタをも含むことができる。

モジュール４０６とエンティティ４０４は、スキーマ定義モデル４００において図２の実際のデータ２０３として描かれていないが、代わりにメタデータ３０２を有するものとして示されている。特性の観察４０８は、データタイプ４１０の形式でメタデータ３０２を有するものとしても示される。データタイプ４１０は、図２の物理テーブル２１８を結果的にポピュレートすることとなるデータ２０３のタイプを指定することができる。

特性の観察４０８のためのデータタイプ４１０は、整数データ、実データ、テキストデータ、長いテキストデータ、日付、日時、選択データ、モジュールポインタデータ、およびエンティティポインタデータを指定することができる。データタイプ４１０のメタデータ３０２を活用することにより、図２のＥＴＬツール２１６は図２の管理エンジン２０８によって自動的に生成されることとなる。ＥＴＬツール２１６の生成については、図８を参照して以下に詳細に説明する。

図３のエンティティタイプテーブル３０６とモジュールタイプテーブル３１０とのリカーシブ関係により、エンティティ４０４とモジュール４０６はそれぞれ、サブエンティティおよびサブモジュールを含むことができる。サブエンティティは、特定のエンティティ４０４から生じるエンティティ４０４でありえる。サブモジュールは、特定のモジュール４０６から生じるモジュール４０６でありえる。

ここで図５を参照すると、そこには、本発明の実施の形態に係る例示的なスキーマ定義モデルテーブル５００が示されている。スキーマ定義モデルテーブル５００は、説明を容易にするためにシンプル化したフォーマットにおいて示される。

スキーマ定義モデルテーブル５００は、複数の行および列を有するものとして示される。各行は特性の観察４０８に対応する。テーブルのセルは、図２のオペレーショナルデータストアの物理テーブル２１８をポピュレートすることとなる現実のデータ２０３ではなくメタデータ３０２で埋められる。

図４と同様に、特性の観察４０８は、エンティティタイプ２２０およびモジュールタイプ２２４とリンクされることができる。エンティティタイプ２２０は第１列によって表されることができ、モジュールタイプ２２４は第２列によって表されることができる。同様に、特性の観察４０８の行は、特性の観察４０８の他の特徴を示す列を通過することとなる。特性の観察４０８は、次のものと関連付けられることができる。すなわち、ディスプレイ特性５０２、シーケンス５０４、特性の名称５０６、データタイプ４１０、選択タイプ５０８、垂直インジケータ５１０、対象エンティティタイプ５１２、対象モジュールタイプ５１４、測定単位５１６、多数の選択インジケータ５１８、および保護インジケータ５２０である。

第１列のエンティティタイプ２２０は、特性の観察４０８が関連付けられるエンティティ４０４でありえる。エンティティタイプ２２０は、先行するヘルスケア分野の例を活用するならば、例えば、患者、サンプル、実験、遺伝的変種、病院、または外科医を含むことができる。第２列のエンティティタイプ２２４は、特性の観察４０８が関連付けられるモジュール４０６でありえる。モジュールタイプ２２４は、患者情報（エンティティ４０４のための非経年的な特性の観察４０８を含むための特別なモジュール）、がん診断、化学療法、薬物療法、照射、外科手術、処置、病理および生活機能、同意、サンプル情報、実験情報、遺伝的変種の観察、その他を含むことができる。

第３列のディスプレイ特性５０２は、特性の観察４０８がモジュール４０６のためのデフォルトＩＤ特性として表示されるべきが否かを示すことができる。ディスプレイ特性５０２は、特性の観察４０８を特定された特性または特定されていない特性であるとして特定することができる。患者エンティティの患者情報モジュールと関連付けられた、特定された特性の一例は、患者ＩＤでありえる。患者エンティティの診断モジュールと関連付けられた、特定された特性の一例は、ＩＣＤ９値でありえる。患者エンティティの患者情報モジュールと関連付けられた、特定されていない特性の一例は、この特性がエンティティ４０４と共に機能するデフォルト値としてあまり役に立たないであろうことから、誕生日でありえる。

第４列のシーケンス５０４は、特性の観察４０８のモジュール４０６内への表示可能順序を示すことができる。第５列の特性の名称５０６は、名称によって特性を特定することができる。薬物療法モジュールの特性の名称５０６の一例として、特性の観察４０８は、投薬量、投薬頻度、薬剤名、投薬順、薬物療法処置、または薬物療法診断として特定されることができる。各モジュールタイプ２２４は、物理テーブル２１８において特性の観察４０８へマッピングされるデータ２０３に対応する独自の特性の名称５０６を含むことができる。

第６列のデータタイプ４１０は、特性の観察４０８が格納されることとなるデータのタイプを示すことができる。特性の観察４０８は、整数データ、実データ、テキストデータ、長いテキストデータ、日付データ、日時データ、選択データ、モジュールポインタ、およびエンティティポインタを特定することができる。

第７列の選択タイプ５０８は、データタイプ４１０が選択データに対応するならば、用いられることとなる。選択タイプ５０８は、選択データに関連付けられた特性の観察４０８のためのすべての有効な選択のリストでありえる。選択タイプ５０８の一例として、はい／いいえや男性／女性を含むことができる。選択タイプ５０８は、処置または化学療法モジュールのための潜在的な化学療法タイプのリストのような長いものを含むこともできる。選択タイプ５０８のこのタイプは、次のものを含むリストであってもよい。すなわち、塩酸メクロレタミン、シクロフォスファミド、クロラムブシル、メルファラン、イフォスファミド、チオテパ、ヘキサメチルメラミン、アルトレートアミン、塩酸プロカルバジン、ダカルバジン、テモゾロミド、カルムスチン、ロムスチン、ストレプトゾシン、カルボプラチン、シスプラチン、オキサリプラチンなどである。

第８列の垂直インジケータ５１０は、特性の観察４０８がどのようにしてオペレーショナルデータストア２０６の物理テーブル２１８に格納されることとなるかを示すことができる。垂直インジケータ５１０が、特性の観察４０８が垂直に格納されていないことを示す「Ｎ」であるなら、特性の観察４０８は、当該特性が関連付けられているモジュール４０６を表すテーブルにおける、ある列に格納されることとなる。垂直インジケータ５１０が、特性の観察４０８が垂直に格納されていることを示す「Ｙ」であるなら、それぞれ別々の行を有する特性の観察４０８が別々のテーブルに格納されることとなる。

第９列の対象エンティティタイプ５１２は、データタイプ４１０がエンティティポインタであるならば用いられることとなる。対象エンティティタイプ５１２は、特性の観察４０８が関連付けられているモジュール４０６によって参照されるエンティティタイプ２２０を示すために用いられることができる。一例として、エンティティポインタに対応し、がん診断モジュールと関連付けられている特性の観察４０８のひとつは、がん診断が生体組織検査の結果であるならば、「サンプル」のエンティティタイプ２２０を参照してもよい。

第１０列の対象モジュールタイプ５１４は、データタイプ４１０がモジュールポインタであるならば用いられることとなる。対象モジュールタイプ５１４は、特性の観察４０８が関連付けられているモジュール４０６によって参照されるモジュールタイプ２２４を示すために用いられることができる。一例として、モジュールポインタに対応し、照射モジュールと関連付けられている特性の観察４０８のひとつは、「処置」のモジュールタイプ２２４を参照してもよい。

第１１列の測定単位５１６は、数字である場合の特性の観察４０８について測定単位を示すために用いられることができる。一例として、測定単位５１６はポンドやキログラムでありえる。

第１２列の複数選択インジケータ５１８は、データタイプ４１０が、ユーザが複数選択できるか１つだけ選択できるかを示す選択であるとき、活用されることができる。一例として、複数選択インジケータ５１８が「Ｎ」であれば、１つの選択のみが有効であり、複数選択インジケータ５１８が「Ｙ」であれば、複数の選択が有効である。

第１３列の保護インジケータ５２０は、その特性が取り扱いに慎重を要する情報を示すか否かを示すことができる。例えば、保護インジケータ５２０が「Ｎ」であれば、この特性は患者を特定する情報を含んでいることがあり、異なる取り扱いがなされるべきである。

スキーマ定義モデルテーブル５００は、オペレーショナルデータストア２０６の物理テーブル２１８を生成するために用いられることとなる。各モジュール４０６は、オペレーショナルデータストア２０６内の別々のテーブルとなる。各特性の観察４０８は、それらが関連付けられるモジュール４０６のテーブル内の列となる。データ２０３は、物理テーブル２１８内のセルを占有することとなる。

ここで図６を参照すると、そこには、本発明の実施の形態に係る例示的な物理テーブル２１８が示されている。物理テーブル２１８は、図２のオペレーショナルデータストア２０６の物理テーブル２１８でありえる。

以下に説明するように、物理テーブル２１８は、図３のメタデータ３０２を参照することによって生成されることができる。メタデータ３０２は、図１のスキーマ定義言語１２６内に、単独で含まれるか、図３のメタデータテーブル３００に表されるスキーマ定義言語１２６と、図４のスキーマ定義モデル４００と、図５のスキーマ定義モデルテーブル５００との組み合わせとして含まれる。物理テーブル２１８は、図４の特性の観察４０８の少なくとも一つに基づいて、図４の互いにリンクを有するモジュール４０６とエンティティ４０４のためのテーブルを含むことができる。

既に説明したヘルスケアの例を続け、スキーマ定義言語１２６を活用すると、物理テーブル２１８は、モジュールタイプ２２４の列において定義されたモジュール４０６またはスキーマ定義モデルテーブル５００の第２列に対応するものとして示される。スキーマ定義モデルテーブル５００において定義された各モジュール４０６は、物理テーブル２１８の完全なリストにおいて創作される独自の物理テーブル６０２を有する。

物理テーブル２１８は、テーブルタイトル６０４と、それから列名称６０６のリストとを有することができる。列名称６０６は、スキーマ定義モデルテーブル５００の行に含まれる特性の観察４０８である。さらに、スキーマ定義モデルテーブル５００の特性の観察４０８がモジュールポインタまたはエンティティポインタであるときは、これらの特性の観察４０８はリンク６０８として物理テーブル２１８に描かれる。一般的に、リンク６０８は、１対１関係または多対１関係を含むことができる。

例えば、エンティティテーブル６１０は、ＯＤＳ＿ＰａｔｉｅｎｔＩｎｆｏテーブル６１２と１対１関係を有することができる。このことは、エンティティテーブル６１０は、エンティティごとに、ＯＤＳ＿ＰａｔｉｅｎｔＩｎｆｏテーブル６１２を指し示す一つの外来キーを含むこととなることを意味する。同様に、ＯＤＳ＿ＰａｔｉｅｎｔＩｎｆｏテーブル６１２は、エンティティテーブル６１０を指し示す外来キーを含むこととなる。

物理テーブル２１８は、多対１リンクをさらに含むことができる。例えば、ＯＤＳ＿ＰａｔｉｅｎｔＩｎｆｏテーブル６１２は、複数のＯＤＳ＿Ｍｅｄｉｃａｔｉｏｎテーブル６１４から多数の外来キーを含むことができるが、各ＯＤＳ＿Ｍｅｄｉｃａｔｉｏｎテーブル６１４は、ＯＤＳ＿ＰａｔｉｅｎｔＩｎｆｏテーブル６１２のために単一の外来キーのみを含むこととなる。

スキーマ定義言語１２６を利用することによって表される別の解決策は、垂直インジケータ５１０のフラグによってもたらされる。典型的には、垂直インジケータ５１０のフラグが否定的または「Ｎ」であるときは、スキーマ定義モデルテーブル５００における各特性の観察４０８は、物理データテーブル２１８における列となる。このことはＯＤＳ＿ＬａｂｓＶｉｔａｌｓテーブル６１６によって説明される。しかしながら、特性の観察４０８が非常に多いときは、垂直インジケータ５１０は肯定または「Ｙ」に設定されることができる。垂直インジケータ５１０が肯定のときは、特性の観察４０８は物理データテーブル２１８内の列として構成されるべきではないが、ＯＤＳ＿ＬａｂｓＶｉｔａｌｓ＿Ｖｅｒｔｉｃａｌテーブル６１８として説明される別のテーブル内の行として占有すべきである。一例として、白血球数や赤血球数のような特性の観察４０８が、他の数多くの特性に沿ってＯＤＳ＿ＬａｂｓＶｉｔａｌｓ＿Ｖｅｒｔｉｃａｌテーブル６１８を占有しうる。

図７、８、９、１１、１３、および１５のフローチャートのためのデータ要件と同様に、図１〜６に関し説明されるデータ要件は、非一時的なコンピュータで読み取り可能なメディアに固定されるかセーブされることができる。これらのデータ要件は、ハードウェアの利用および実施なしにはアクセスされ又は変更されることはできず、データ値の変化は、ビット形式でハードウェア記録の物理的かつ非一時的な変換を表すことができる。

図２のオペレーショナルデータストア２０６の実施と利用のためのデータ要件について説明したが、オペレーショナルデータストア２０６の実施と利用のためのプロセスについてこれから説明する。図７、８、９、１１、１３、および１５に関し説明されるフローチャートにおいて、オペレーショナルデータストア２０６の実施と利用のためのプロセスのステップは、ハードウェア、ソフトウェア、ファームウェア、またはそれらの組み合わせにおいて実現されることができる。さらに、ステップの境界は一般に多種多様であり、異なる実施の形態において機能は共に実施されたり別々に実施されたりする。

ここで図７を参照すると、そこには、本発明の実施の形態に係る、オペレーショナルデータストアを実施しポピュレートするための例示的な制御フロー７００が示されている。一例として、図２のオペレーショナルデータストア２０６は、同様に実施されポピュレートされてもよい。

制御フロー７００は、スキーマ定義言語提供ステップ７０２を含む。スキーマ定義言語提供ステップ７０２は、スキーマ定義言語１２６を提供するために呼び出されることができる。スキーマ定義言語１２６を提供することによって、設計者はデータおよびメタデータ構造を活用することができる。

スキーマ定義言語提供ステップ７０２から続くのは、スキーマ定義モデル化ステップ７０４である。スキーマ定義モデル化ステップ７０４の間、設計者は、存在するファイル、存在するオペレーショナルデータストア、または存在するデータベースに含まれるデータ要素を用いてスキーマ定義モデル４００を定義するためのスキーマ定義言語１２６を活用することとなる。スキーマ定義言語１２６は、図２および図３に関し上記詳述したメタデータおよびデータ構造を活用することにより設計者によって実際に実現される。

スキーマ定義モデル化ステップ７０４は、スキーマ定義モデル獲得ステップ７０６へと続くことができる。スキーマ定義モデル獲得ステップ７０６の間、スキーマ定義モデル４００は、各特性の観察４０８の各行を提供するとともにそれらを図４のエンティティ４０４およびモジュール４０６に付与するか関連付けるスキーマ定義モデルテーブル５００内で獲得されることができる。スキーマ定義モデル獲得ステップ７０６はスキップされてもよく、スキーマ定義言語１２６は、メタデータ３０２を参照しクエリを実行するためのスキーマ定義モデルテーブル５００の代わりに用いられることができる。スキーマ定義言語１２６は、図３のメタデータテーブル３００、スキーマ定義モデル４００、またはそれらの組み合わせとして用いられることができる。

スキーマ定義モデル獲得ステップ７０６は、オペレーショナルデータストア（ＯＤＳ）生成ステップ７０８へと続くことができる。ＯＤＳ生成ステップ７０８は、スキーマ定義モデルテーブル５００内に含まれるスキーマ定義言語１２６からオペレーショナルデータストア２０６の物理テーブル２１８を生成し、それらの間に図６のリンク６０８を創作することを含む。

特に、ＯＤＳ生成ステップ７０８の間、物理テーブル２１８のひとつは、モジュール４０６ごとにまず生成される。スキーマ定義モデルテーブル５００の垂直インジケータ５１０が「Ｎ」であるならば、その後特性の観察４０８に関連付けられたモジュール４０６のために図６の物理テーブル６０２においてひとつの列が創作される。この列が特性の観察４０８のために創作されたときは、図５のデータタイプ４１０のインジケータは、この列が含むこととなるデータのタイプを特定する。

ＯＤＳ生成ステップ７０８の間に、選択テーブルを参照するためのデータタイプ４１０の選択の特性の観察４０８のために、外来キーが生成されることになる。同様に、ＯＤＳ生成ステップ７０８の間に、対象エンティティタイプ５１２におけるインジケータを含むかスキーマ定義モデルテーブル５００の対象モジュールタイプ５１４を含む特性の観察４０８のために、外来キーが生成されることになる。対象エンティティタイプ５１２がインジケータを含むならば、図６のエンティティテーブル６１０を参照する外来キーが生成されることとなる。一方、対象モジュールタイプ５１４がインジケータを含むならば、モジュールテーブルのうちの一つを参照する外来キーが創作されることとなる。

スキーマ定義モデルテーブル５００の垂直インジケータ５１０が「Ｙ」であるならば、その後特性の観察４０８のために列は生成されない。代わりに、特性の観察４０８のタイプは、一行につき一つの特性の観察４０８を有する垂直テーブルに関連付けられたモジュール４０６にロードされることとなる。最後に、経年的なタイムスタンプに対応する特性の観察４０８は、モジュール４０６の物理テーブル２１８と関連付けられることとなる。

ＯＤＳ生成ステップ７０８は、ＥＴＬ生成ステップ７１０へと続く。ＯＤＳ生成ステップ７０８の物理テーブル２１８が、スキーマ定義モデル獲得ステップ７０６において完成されたスキーマ定義モデルテーブル５００に沿って一度完成されたときは、ＥＴＬツール２１６は、スキーマ定義モデルテーブル５００とスキーマ定義言語１２６とに基づいて自動的に生成されることができる。ＥＴＬツール２１６の生成については、図８を参照して以下に詳細に説明する。

ＥＴＬ生成ステップ７１０は、ＯＤＳポピュレートステップ７１２へと続く。ＥＴＬツール２１６がスキーマ定義モデルテーブル５００とスキーマ定義言語１２６とに基づいて一度自動的に生成され、かつ、物理テーブル２１８が一度創作されたときは、ＥＴＬツール２１６はＯＤＳポピュレートステップ７１２において活用されて、図２の外部ソース２０４からデータ２０３が抽出され、図２のデータ２０３がデータタイプ４１０、選択タイプ５０８、またはスキーマ定義モデルテーブル５００の他の列に準拠したフォーマットに変換される。データ２０３がスキーマ定義モデルテーブル５００とスキーマ定義言語１２６の要件に一度準拠すると、データ２０３は、オペレーショナルデータストア２０６の物理テーブル２１８へロードされる。

図８、９、１１、１３、および１５のフローチャートにおいて、スキーマ定義言語１２６、スキーマ定義モデル４００、またはスキーマ定義モデルテーブル５００を含む要素を参照しまたは利用する際は、それらのうち１つ又はそのいくつかの組み合わせが名付けられた要素の代わりに又はそれと共に参照され利用されることができると考えられる。説明を容易にするため、スキーマ定義モデルテーブル５００は、フローチャートの参照のための例として一般的に用いられる。

ここで図８を参照すると、そこには、本発明の実施の形態に係る、抽出、変換、ロード関数を生成するための例示的な制御フロー８００が示されている。制御フロー８００は、図１のスキーマ定義言語１２６を参照することにより、図２のＥＴＬツール２１６を自動的に生成する例示的な方法を示す。スキーマ定義言語１２６は、図３のメタデータテーブル３００、図４のスキーマ定義モデル４００、図５のスキーマ定義モデルテーブル５００、またはその組み合わせ内に含まれるメタデータ３０２に関し参照されることができる。以下に説明されるとおり、図２の物理テーブル２１８は、メタデータ３０２にしたがって、ＥＴＬツール２１６を自動的に生成することによって、図２のデータ２０３でポピュレートされることができる。

一般的に、図２の外部ソース２０４からのデータ２０３は、図２のオペレーショナルデータストア２０６に最終的に格納される前に、非準拠ステージングテーブル８０２と準拠ステージングテーブル８０４とを通過して流れる。図２の管理エンジン２０８は、スキーマ定義言語１２６から非準拠ステージングテーブル８０２と準拠ステージングテーブル８０４とを自動的に生成することができる。

クリーンでないソースデータであるデータ２０３は、準拠ステージングテーブル８０４へ移動する前に非準拠ステージングテーブル８０２においてまず解析されスクラブされなければならない。アダプタとＡＰＩは、データ２０３を解析し、シンタックスの検証が失敗した記録を追い出すために備えられることができる。クリーンなデータ２０３は、準拠ステージングテーブル８０４へ直接流れることができる。テーブルとデータベースレベルの検証は、準拠ステージングテーブル８０４において実施されることができる。

ＥＴＬツール２１６のルーティンは、これがデータを非準拠ステージングテーブル８０２および準拠ステージングテーブル８０４からオペレーショナルデータストア２０６に移動させるのであるが、自動的に生成されることができる。このプロセスは、ステップ８０６〜８２４に関し、以下に詳細に説明される。

最初に、リトリーブステップ８０６が、非準拠ソースデータとしてのデータ２０３をリトリーブすることができる。これはフラットファイル形式でありえるが、データは利用可能な形式であればよいと考えられる。フラットファイルとして、データ２０３は、データ２０３のテキスト列タイプのものでありえる。ソースデータは、図４のエンティティ４０４とモジュール４０６とに対応するデータ２０３を含むことができる。一例として、非準拠ステージングテーブル８０２におけるソースデータは、患者情報フラットファイルを含むことができ、これにより図２のエンティティ４０４とエンティティタイプ２２０のための非経年的なデータを保持する特別なモジュールタイプに対応することができる。

非準拠ステージングテーブル８０２は、図２のモジュール４０６とモジュールタイプ２２４とに対応するモジュールテーブルをさらに含むことができる。一例として、非準拠ステージングテーブル８０２は、診断モジュールタイプ２２４とがん診断モジュール４０６とに対応するがん診断のフラットファイルを含むことができる。

モジュール４０６に対応する非準拠ステージングテーブル８０２におけるデータ２０３は、関連付けられたエンティティ４０４を指し示す外来キーを含むことができる。一方、エンティティ４０４に対応する非準拠ステージングテーブル８０２におけるデータ２０３は、エンティティ４０４の非経年的なデータを保持するためだけに特別に創作されたモジュール４０６と同様に、エンティティ４０４の主要キーとしての主要キー（患者ＩＤなど）を含むことができる。

リトリーブステップ８０６は、プロセスステップ８０８へと続く。プロセスステップ８０８は、スキーマ定義言語１２６のメタデータ３０２を収集し、かつ／または整理し、選択タイプ準拠ステージテーブル８１０および選択準拠ステージテーブル８１２とする。スキーマ定義言語１２６から利用可能な、各観察された選択は、選択タイプ準拠ステージテーブル８１０に置かれることができ、かつ、主要キー、性別のような選択タイプＩＤ、民族性、ＩＣＤ９などが付与されることができる。

選択準拠ステージテーブル８１２は、選択タイプ準拠ステージテーブル８１０の外来キーおよび利用可能な各選択の主要キーを含むことができる。選択は、男性、女性、コーカシアン、ヒスパニック、アジア系、１７３．０−悪性・・・、１７４．４−パジェットまたは１７４．６−悪性新生物などを含みうる。最終更新日も、選択タイプ準拠ステージテーブル８１０および選択準拠ステージテーブル８１２に含められることができる。インクリメンタルロードを実施する際、オペレーショナルデータストア２０６から利用可能な選択が可能である。

プロセスステップ８０８に続くのは、準拠ロードステップ８１４である。準拠ロードステップ８１４は、準拠ステージングテーブル８０４を含むことができる。メタデータテーブル３００、スキーマ定義モデルテーブル５００、またはスキーマ定義モデル４００内に格納された図４のモジュール４０６と特性の観察４０８のためのスキーマ定義言語１２６のメタデータ３０２内に含まれる定義は、データがどのようにして準拠ステージングテーブル８０４へロードされるべきであるかを特定するために用いられることできる。例えば、メタデータ３０２は、図４のデータタイプ４１０が日付であることを要求してもよい。その場合、非準拠ステージングテーブル８０２から抽出されたデータ２０３が、それが準拠ステージングテーブル８０４へロードされる際に日付形式であるべきである。

非準拠ステージングテーブル８０２内に含まれるエンティティ４０４は、準拠ステージングテーブル８０４へロードされることができる。準拠ステージングテーブル８０４の各列は、エンティティ４０４の単一の例を含むことができる。各エンティティ４０４は、準拠ステージングテーブルの主要キーを付与される。エンティティ４０４は、エンティティのサブエンティティであるが、ロードされることとなり、親エンティティを指すポインタを与えられる。例えば、患者は、そこから抽出されたサンプルを有していた場合がある。サンプルは、サブエンティティと考えられ、遡って患者を示すポインタを有する。ポインタは、患者の準拠ステージングテーブルの主要キーでありえる。非経年的なデータ２０３ではなくエンティティ４０４それ自身は、まず準拠ステージングテーブル８０４へロードされる。

エンティティ４０４が準拠ステージングテーブル８０４に一度ロードされたときは、モジュール４０６と関連付けられたデータ２０３は、準拠ステージングテーブル８０４にロードされることができる。準拠ロードステップ８１４において、非準拠ステージングテーブル８０２は開放されており解析される。

非準拠ステージングテーブル８０２の各行が処理され、準拠ロードステップ８１４は、データ２０３の値を対象データタイプ４１０に変換し、非ゼロの特性の観察４０８が確実に特性値を持つようにし、この特性の観察４０８についての有効な制限を証明する。特性の観察４０８についての制限が証明されたときは、日付および数字の特性の観察４０８の値の範囲についての制限は証明され、テキストの特性の観察４０８の有効な文字や有効な長さが証明され、かつ、エンティティ４０４への有効な参照が証明される。他のモジュール４０６への参照の有効性の証明は、第２パスの間におこなわれる。

準拠ロードステップ８１４の間のエラーは、エラーテーブル８１６に置かれることとなるモジュール４０６のうちの一つと関連付けられたレコードを生じさせる。処理が成功した各行には、独自準拠ステージングテーブルの主要キーが付与されることとなる。準拠ステージングテーブル８０４は、主要キーおよび外来キーを示す第１行と、列のデータタイプ４１０を示す第２行と、準拠ステージングテーブル８０４の列名称を示す第３行とを含むことができる。準拠ステージングテーブル８０４は、他のモジュール４０６を参照している特性の観察４０８を除いて、オペレーショナルデータストア２０６を反映する。

上述のフラットファイルの例を続けると、フラットファイルのテキストの値は適切なデータタイプ４１０に変換されることができる。そして、エンティティ４０４への参照が、準拠ステージングテーブルの主要キーに置き換えられる。

あるレコードが、準拠ロードステップ８１４の有効性チェックに失敗したときは、このレコードは、エラーテーブル８１６に置かれることができる。例えば、エンティティ４０４の非経年的なデータ２０３を含むレコードが不適切な誕生日を含むときは、このレコードはエラーテーブル８１６に置かれることができる。さらに、データがエラーテーブル８１６におけるエンティティ４０４を参照するモジュールに対応するときは、このモジュール４０６のレコードはエラーテーブル８１６内にも置かれる。

モジュール４０６が準拠ロードステップ８１４における準拠ステージングテーブル８０４に一度ロードされたときは、モジュール４０６間のレファレンスはアップデートステップ８１８においてアップデートされることができる。アップデートステップ８１８は、準拠ロードステップ８１４から続くが、すべてのモジュール４０６が準拠ステージングテーブル８０４にロードされた後にのみ、レファレンスを含むことによって、モジュール４０６の適切な従属性を確実にする。

アップデートステップ８１８は、ステージングテーブル８０４内で他のモジュール４０６を参照する各特性の観察４０８毎に２つの予備列を創作することができる。この２つの予備列は、参照されたモジュールの外来キー同様に参照されたモジュールの名称を含むことができる。一例として、処置は診断を参照し、特性の観察４０８は、診断および診断外来キーを取り扱う追加的な列を含むこととなる。

参照されたモジュールの外来キーを含む列は、参照されたモジュール４０６の準拠ステージングテーブルの主要キーを含むことができる。この時点では、参照先が無効または欠落している特性の観察４０８の場合、エラーテーブル８１６におけるモジュール４０６は削除され、エラーテーブル８１６内に置かれる。アップデートステップ８１８はアダプタを含むことができ、プロセスのこの時点で、インストールによってそれら自身のカスタム検証をおこなうことができる。

アップデートステップ８１８に続くのは、オペレーショナルデータストアロードステップ８２０である。アップデートステップ８１８の後、準拠ステージングテーブル８０４は検証されたデータを含むことができる。オペレーショナルデータストアロードステップ８２０は、準拠ステージングテーブル８０４ごとに、ＳＱＬサーバーマージステートメントを生成する。オペレーショナルデータストアロードステップ８２０は、選択タイプ準拠ステージテーブル８１０のためのＳＱＬサーバーマージステートメントを生成することができ、それから選択準拠ステージテーブル８１２、それからエンティティ４０４を含む準拠ステージングテーブル８０４、それからエンティティ４０４の非経年的なデータ２０３を含む準拠ステージングテーブル８０４、そして最後に他のモジュール４０６の準拠ステージングテーブル８０４のためのＳＱＬサーバーマージステートメントを生成することができる。

準拠ステージングテーブル８０４内のデータ２０３は、すべて検証されているので、環境の問題のみがマージの失敗を引き起こしうる。環境の問題は、十分でないディスク容量などの問題を含みうる。マージが失敗したときは、オペレーショナルデータストアロードステップ８２０はエラーを記録して中止される。

オペレーショナルデータストアロードステップ８２０に続くのは、デリートステップ８２２である。デリートステップ８２２は、オペレーショナルデータストア２０６へのインクリメンタルロードの間に適用されるインクリメンタルロードの間、デリートフラグは準拠ステージングテーブル８０４およびＯＤＳにロードされる。デリートステップ８２２は、削除される記録がオペレーショナルデータストア２０６に存在しないことを検証する。削除されるレコードがオペレーショナルデータストア２０６に存在しないときは、このレコードはエラーテーブル８１６へ送られる。ロードが一度完了すれば、デリートステップ８２２は、参照の整合性を確実にするためにカスケードデリートフラグを有するレコードを削除する。

デリートステップ８２２に続くのは、トランケートステップ８２４である。トランケートステップ８２４は、ロードが成功したときは、後続のインクリメンタルロードに備えるために、すべての準拠ステージングテーブル８０４にトランケートをおこなうことができる。データ２０３がオペレーショナルデータストア２０６に一度ロードされたときは、ユーザは、図９〜１５に関し以下詳細に説明される図１のビジネスインテリジェンスツール１３４を用いて、データ２０３を完全に活用しそこへアクセスすることができる。

ここで図９を参照すると、そこには、本発明の実施の形態に係る、コホートをフィルタリングするための例示的な制御フロー９００が示されている。例示的な制御フロー９００は、図１のフィルタ１２８がどのようにして図１のスキーマ定義言語１２６に対して動作するのかについての例示的な説明図でありえる。スキーマ定義言語１２６のメタデータ３０２は、図３のメタデータテーブル３００、図５のスキーマ定義モデルテーブル５００、図４のスキーマ定義モデル４００、またはそれらの組み合わせから参照されることができる。

一例として、図２のオペレーショナルデータストア２０６がポピュレートされ次第、ＯＤＳポピュレートステップ７１２において、図１のビジネスインテリジェンスツール１３４は、それらがスキーマ定義言語１２６に対して動作することから、完全に機能的である。オペレーショナルデータストア２０６がポピュレートされたとき、トータルコホート９０２が利用できるようになる。トータルコホート９０２は、オペレーショナルデータストア２０６内に表される図４のエンティティ４０４のすべてを含むことができる。

トータルコホート９０２は、オペレーショナルデータストア２０６をフィルタリングするための開始点でありえる。トータルコホート９０２のエンティティ４０４は、スキーマ定義言語１２６内の図４の特性の観察４０８のいずれかを用いてフィルタリングされることができる。スキーマ定義言語１２６内の特性の観察４０８は、特性の観察４０８と関連付けられた図３のメタデータ３０２によって特定されることができる。

特性選択ステップ９０４において、これはＯＤＳポピュレートステップ７１２から続くが、ユーザは選択された特性９０５を選択することができる。選択された特性９０５は、特性の観察４０８のうちの一つでありえる。上記活用されたヘルスケアの例の延長として、ユーザは、乳がんについてＩＣＤ９診断がされたエンティティ４０４の患者クラスの特定を望むことがある。

ビジネスインテリジェンスツール１３４は、有効ＩＣＤ９選択などのすべての特性の観察４０８を、スキーマ定義言語１２６からリターンする。ユーザは、選択された特性９０５として、ＩＣＤ９特性を選択し、かつ乳がんに対応するＩＣＤ９コードのみのために選択された特性９０５をフィルタリングするなどして、特性の観察４０８の一つを選択し、選択された特性９０５をさらにフィルタリングすることができる。

トータルコホート９０２をフィルタリングするための選択された特性９０５をユーザが選択した後に、ビジネスインテリジェンスツール１３４は、図４のモジュール４０６のためのスキーマ定義言語１２６と、メタデータクエリステップ９０６において選択された特性９０５と関連付けられたエンティティ４０４とについてクエリを実行することができる。スキーマ定義言語１２６のクエリは、モジュール４０６と、エンティティ４０４と、選択された特性９０５に関連する他の特性の観察４０８についてメタデータ３０２をリターンすることができる。さらに、選択された特性９０５に関連付けられたモジュール４０６とエンティティ４０４とは、図２の物理データテーブル２１８内で特定されることができる。ビジネスインテリジェンスツール１３４は、選択された特性９０５に関連付けられた図２のエンティティタイプ２２０とモジュールタイプ２２４をさらにリターンすることができる。

スキーマ定義言語１２６に対しクエリが実行された後に、メタデータクエリステップ９０６から続く特性関連付けステップ９０８は、選択された特性９０５に関連付けられたスキーマ定義言語１２６からモジュール４０６とエンティティ４０４とをリターンすることができる。選択された特性９０５がエンティティ４０４にのみ関連付けられているときは、いずれのモジュール４０６も選択された特性９０５には関連付けられず、エンティティ４０４のみがリターンされる。

選択された特性９０５に関連付けられたエンティティ４０４とモジュール４０６のリターンで、特性関連付けステップ９０８から続く計算ステップ９１０は、現在のコホート９１２とすべてのワンホップリンケージ９１４とを計算することができる。計算ステップ９１０が現在のコホート９１２を計算したときは、スキーマ定義言語１２６は、選択された特性９０５を有する患者に対応するオペレーショナルデータストア２０６の物理テーブル２１８の位置を特定するために用いられることができる。

選択された特性９０５に関連付けられたエンティティ４０４の図２のデータ２０３を抽出するために、スキーマ定義言語１２６のメタデータ３０２に基づいて、クエリが生成される。計算ステップ９１０は、物理テーブル２１８にクエリを実行し、リンク６０８と、特性の観察４０８、モジュール４０６、およびエンティティ４０４の図６の物理テーブル６０２の位置を特定することにより、選択された特性９０５に関連付けられた現在のコホート９１２をリターンするためのＳＱＬ命令９１５を自動的に生成することができる。スキーマ定義言語１２６は、データ２０３が物理的に位置する物理データテーブル２１８ごとに複数列を検出するために用いられることができるメタデータテーブル３００として参照されることができる。

ビジネスインテリジェンスツール１３４は、選択された特性９０５に関連付けられたエンティティ４０４の数として、現在のコホート９１２をリターンすることができる。計算ステップ９１０は、ワンホップリンケージ９１４を計算し、ユーザがさらにフィルタ１２８をリファインするためのオプションとしてそれらを提示することもできる。

ワンホップリンケージ９１４は、エンティティ４０４に対応する他の選択されていない特性の観察４０８と選択された特性９０５が対応するモジュール４０６とでありえる。つまり、ワンホップリンケージ９１４は、選択された特性の観察４０８が関連付けられた同じモジュール４０６とエンティティ４０４から選択されていない特性である。選択されていない特性の計算に応じて、計算ステップ９１０は、ワンホップリンケージ９１４としてモジュール４０６とエンティティ４０４をもリターンすることができる。選択された特性９０５と関連付けられたモジュール４０６とエンティティ４０４は、関連付けられていないモジュール４０６またはエンティティ４０４によって指し示され、これら関連付けられていないモジュール４０６またはエンティティ４０４は、ワンホップリンケージ９１４としてリターンされることができる。つまり、いずれかの特性の観察４０８の図５の対象エンティティタイプ５１２または図５の対象モジュールタイプ５１４が、選択された特性９０５と関連付けられたモジュール４０６またはエンティティ４０４を指すデータポインタを含むときは、そのデータポインタを有する特性の観察４０８に関連付けられたモジュール４０６およびエンティティ４０４は、ワンホップリンケージ９１４としてリターンされることとなる。

乳がんに基づいてフィルタリングする例を活用して、ワンホップリンケージ９１４の計算を説明すると、計算ステップ９１０は、エンティティ４０４に対応する年齢、性別、体重、その他の非経年的な特性の観察４０８と関連付けられたエンティティ４０４のワンホップリンケージ９１４を計算することができる。計算ステップ９１０はさらに、モジュール４０６に対応する診断日、診断時年齢、原発巣部位、その他の非経年的な特性の観察４０８などの選択された特性９０５に関連付けられたモジュール４０６のワンホップリンケージ９１４も計算することができる。

計算ステップ９１０は、選択された特性９０５と関連付けられていないその他のモジュール４０６またはエンティティ４０４のワンホップリンケージ９１４もリターンすることができる。例えば、特性の観察４０８が乳がんについてのＩＣＤ９が含まれたユーザによって選択されたときは、ＩＣＤ９特性は診断モジュールに対応し、計算ステップ９１０は、処置でフィルタリングするオプションをユーザにリターンすることができる。なぜなら、処置モジュールは、診断モジュールに対し対象モジュールタイプ５１４におけるポインタを有するからである。

計算ステップ９１０に続くのは、他の特性選択オプション９１６である。ユーザがより多くの特性の観察４０８を選択しないと決定したときは、他の特性選択オプション９１６は、終了ステップ９１８においてフィルタ１２８の動作を終了する。終了ステップ９１８が呼び起こされたときは、現在のコホート９１２は、ビジネスインテリジェンスツール１３４と共にさらに利用されるために、引き続き活用されセーブされることができる。

ユーザが他の特性選択オプション９１６において他の特性を選択することを決定したときは、後続の選択された特性９１９は、他の特性選択オプション９１６に続く他の特性選択ステップ９２０において選択されることができる。ユーザは、選択された特性ステップ９０４における選択された特性９０５をユーザが選択した方法と同じ方法で、後続の選択された特性９１９を選択することができる。

特性選択ステップ９０４とは対照的な他の特性選択ステップ９２０におけるユーザの体験の差異は、他の特性選択ステップ９２０においてユーザは、選択オプションとしてワンホップリンケージ９１４を与えられており、トータルコホート９０２ではなく現在のコホート９１２が表示されることである。

ユーザが後続の選択された特性９１９を一度選択したときは、後続の選択された特性９１９は、他の特性選択ステップ９２０に続く特性リンクステップ９２２において選択された特性９０５にリンクされることができる。特性リンクステップ９２２は、フィルタ１２８をリファインし、現在のコホート９１２を制限するために、選択された特性９０５を後続の選択された特性９１９にリンクすることができる。後続の選択された特性９１９は、フィルタ１２８の現在のエンティティ４０４またはモジュール４０６を制限することになると仮定されるが、ユーザは、この論理ＡＮＤ演算を優先することがあり、後続の特性の観察４０８の論理ＯＲ関数を活用することがあると考えられる。

説明的な一例として、ユーザは、年齢３５〜４０歳または男性のような選択された特性９０５に関連付けられたエンティティ４０４に対応するワンホップリンケージ９１４のうちの一つを選択することがある。ＩＣＤ９乳がんの例を続けると、特性リンクステップ９２２は、第１の選択されたＩＣＤ９特性（選択された特性９０５）を続いて選択された年齢または性別の特性の観察４０８（後続の選択された特性９１９）とリンクするだろう。特性リンクステップ９２２は、選択された特性９０５と後続の選択された特性９１９の両方を組み合わせて、年齢が３５〜４０歳で男性であった患者の乳がんのみについてフィルタ１２８をさらにリファインするだろう。

説明的な第２の例として、ユーザは、診断日２００７のような選択された特性９０５に関連付けられたモジュール４０６に対応するワンホップリンケージ９１４のうちの一つを選択することがある。ＩＣＤ９乳がんの例を続けると、特性リンクステップ９２２は、第１の選択されたＩＣＤ９特性（選択された特性９０５）を続いて選択された日付の特性（後続の選択された特性９１９）とリンクするだろう。特性リンクステップ９２２は、選択された特性９０５と後続の選択された特性９１９の両方を組み合わせて、２００７年の乳がん診断のみについてフィルタ１２８をリファインするだろう。

説明的な第３の例として、ユーザは、モジュール４０６または処置タイプ：外科手術のような選択された特性９０５に関連付けられた特性の観察４０８へのリンケージ６０８に対応するワンホップリンケージ９１４のうちの一つを選択することがある。ＩＣＤ９乳がんの例を続けると、特性リンクステップ９２２は、選択されたＩＣＤ９特性（選択された特性９０５）を続いて選択されたポインタ特性（後続の選択された特性９１９）とリンクするだろう。特性リンクステップ９２２は、選択された特性９０５と後続の選択された特性９１９の両方を組み合わせて、外科手術による処置がなされた乳がん診断のみについてフィルタ１２８をさらにリファインするだろう。

特性リンクステップ９２２は、メタデータクエリステップ９０６へと続く。ユーザが後続の選択された特性９１９を一度選択し、選択された特性９０５と後続の選択された特性９１９とが特性リンクステップ９２２においてリンクされると、メタデータクエリステップ９０６は、上述の方法と同様の方法で、スキーマ定義言語１２６についてクエリを実行することとなる。

メタデータクエリステップ９０６でスキーマ定義言語１２６について一度クエリを実行したときは、特性関連付けステップ９０８は、全ての選択された特性９０５が論理ＡＮＤ関数のように用いられて動作するという点を除いて、上述の方法と同様の方法で動作することができる。同様に、計算ステップ９１０で、上述の方法と同様の方法で後続の選択された特性９１９のワンホップリンケージ９１４を算出することができ、上述の方法と同様の方法でオペレーショナルデータストア２０６の物理テーブル２１８についてクエリを実行するためのスキーマ定義言語１２６を活用することにより現在のコホート９１２をリターンすることができる。

ここで図１０を参照すると、そこには、ビジネスインテリジェンスツール１２６において実現されるようなフィルタ１２８のスクリーンショット１０００が示されている。スクリーンショット１０００は、後続の選択された特性９１９にリンクされた選択された特性９０５の例を描いている。後続の選択された特性９１９は、トータルコホート９０２をフィルタリングするための第２の特性の観察４０８として選択された特性９０５にリンクされることができる。このリンクは、論理ＡＮＤ条件を表すことができるが、ユーザはトータルコホート９０２の論理ＯＲフィルタリングを呼び起こすためのリンクアイコンを切り替えることがある。

トータルコホート９０２は、フィルタ１２８の開始コホートとして示される。選択された特性９０５は、乳がんについてフィルタリングされたＩＣＤ９値であると示される。選択された特性９０５は、後続の選択された特性９１９にコンテキスト上リンクされる。

後続の選択された特性９１９は、２０１０年１月１日と２０１３年１月１日の間の日付をリターンするためにフィルタリングされる診断日であると示される。現在のコホート９１２は、現在のコホート９１２内のエンティティ４０４の数と共にエンティティ４０４のグループとして描かれる。

ここで図１１を参照すると、そこには、本発明の実施の形態に係るパターンを活用するコホートのフィルタリングのための例示的な制御フロー１１００が示されている。例示的な制御フロー１１００は、図１のフィルタ１２８がどのようにして図１のスキーマ定義言語１２６に対して動作するのかについての他のあるいはさらなる例示的な説明図でありえる。スキーマ定義言語１２６のメタデータ３０２は、図３のメタデータテーブル３００、図５のスキーマ定義モデルテーブル５００、図４のスキーマ定義モデル４００、またはそれらの組み合わせから参照されることができる。

これは、図４のエンティティ４０４のクラスを特定し、図２のオペレーショナルデータストア２０６をスキャンすることによって、臨床イベントに対応する図４の特性の観察４０８のうちの特定のシリーズと一致するエンティティ４０４を探すさらに別の方法を表す。ユーザは、臨床パターンを定義して図１のビジネスインテリジェンスツール１３４を利用するため、かつその臨床パターンに一致するエンティティ４０４と、その臨床パターンに一致しないエンティティ４０４とを特定するために、選択された特性９０５として特性の観察４０８を選択することができる。

オペレーショナルデータストア２０６にポピュレートされたとき、図９のトータルコホート９０２が利用できるようになる。トータルコホート９０２は、オペレーショナルデータストア２０６内で表されるエンティティ４０４のすべてを含むことができる。制御フロー１１００は、計算ステップ９１０で計算されたトータルコホート９０２または現在のコホート９１２から動作することができる。この説明的な例においては、現在のコホート９１２を提供する計算ステップ９１０は、パターンに基づいて現在のコホート９１２をフィルタリングするための制御フロー１１００を用いることにより、フィルタ１２８をさらにリファインするために用いられることとなる。

計算ステップ９１０から続くのは、選択された特性９０５として特性の観察４０８が選択されることができる特性選択ステップ１１０２である。ユーザが選択できる特性の観察４０８は、ワンホップリンケージ９１４を含むが、関連のない特性の観察４０８も含むことができる。ユーザが選択された特性９０５を一度選択したときは、ビジネスインテリジェンスツール１３４は特性選択ステップ１１０２から続く特性表示モジュール１１０４において、この特性と現在のコホート９１２とをフィードバックすることとなる。ユーザは、その後特性表示モジュール１１０４から続くオプション選択１１０６において別の特性を選択するオプションを有する。ユーザがより多くの特性の観察４０８を選択したいときは、オプション選択１１０６は、ユーザを特性選択ステップ１１０２へ運ぶこととなり、ユーザは後続の特性を選択することができる。このようにして、ユーザは、臨床イベントに対応する特性の観察４０８を選択し、かつフィルタ１２８を制限するパターンを定義することができる。

上記活用されたヘルスケア分野の例を続けると、ユーザが、退院後３０日以内に再入院した虫垂切除術を受けた患者を特定したいと望んだと仮定する。ユーザは、虫垂切除術についての特性の観察４０８を選択することができ、ビジネスインテリジェンスツール１３４は、図９の制御フローを活用する虫垂切除術を受けたエンティティ４０４全員を検出することができる。虫垂切除術についての特性の観察４０８に関連付けられたすべてのエンティティ４０４が一度現在のコホート９１２において特定されたときは、ユーザは特性選択ステップ１１０２において始まる新たな臨床パターンを創作することができる。ユーザは、入院についての特性の観察４０８に続く退院についての特性の観察４０８を選択することができる。入院についての特性の観察４０８は、退院後３０日以内に生じた入院を示す特性の観察４０８によって制限されることができる。この臨床パターンの例は、最大で３０日間離れたワンホップリンケージ９１４についての制限を選択することにつながる２つの特性の観察４０８（退院と入院）を選択することに関するだろう。上述のように、ワンホップリンケージ９１４は、選択された特性９０５と関連付けられた図４の同じモジュール４０６またはエンティティ４０４に属する選択されていない選択特性の観察４０８である。

ユーザは、「虫垂切除術３０日以内再入院」と名づけられたパターンをセーブする。

ユーザが臨床パターンに対応する特性の観察４０８を選択することによって臨床パターンを定義したときは、ユーザは臨床パターンをセーブすると共にマッチ（一致するもの）計算ステップ１１０８を選択することができる。マッチ計算ステップ１１０８は、図６のリンク６０８と、選択された特性９０５を含んでいる図２の物理テーブル２１８の位置とを特定するために、スキーマ定義言語１２６を参照するメタデータクエリステップ１１１０へと続く。

メタデータクエリステップ１１１０は、ＳＱＬ生成ステップ１１１２へと続く。ＳＱＬ生成ステップ１１１２は、メタデータクエリステップ１１１０におけるスキーマ定義言語１２６からリターンされた物理テーブル２１８の関係と位置とを活用することができ、オペレーショナルデータストア２０６の物理テーブル２１８に対しクエリを実行するためのＳＱＬ命令１１１４を自動的に生成する。

ＳＱＬ実行ステップ１１１６は、ＳＱＬ生成ステップ１１１２へと続くが、オペレーショナルデータストア２０６の物理テーブル２１８に対しクエリを実行するためのＳＱＬ生成ステップ１１１２から自動的に生成される。ＳＱＬ実行ステップ１１１６から続くのは、リターンステップ１１１８である。リターンステップ１１１８は、一致コホート１１２０と不一致コホート１１２２とをリターンすることができる。

一致コホート１１２０は、臨床パターンとして選択された特性９０５に対応するエンティティ４０４でありえる。不一致コホート１１２２は、臨床パターンとして選択された特性９０５に対応しないエンティティ４０４でありえる。

一致コホート１１２０と不一致コホート１１２２は、後の処理のため、またはビジネスインテリジェンスツール１３４によってさらに制限されるためにセーブされる。リターンステップ１１１８が一致コホート１１２０をリターンしたときは、ユーザは、一致コホート１１２０内のエンティティ４０４の詳細について視ることができる。例えば、ユーザは、特性９０５によって定義された臨床パターンに一致するものが発生したときは、そのＩＤを視ることができる。

ここで図１２を参照すると、そこには、図１のビジネスインテリジェンスツール１２６において実現されるような図１のフィルタ１２８のスクリーンショット１２００が示されている。スクリーンショット１２００は、特性の観察４０８の例を描いている。特性の観察４０８は、選択ボックス１２０２においてユーザが選択するために表示されることができる。

ユーザが選択する特性の観察４０８は、パターンボックス１２０４において示されることができる。後続の選択された特性９１９に沿って選択された特性９０５は、パターンボックス１２０４において共にリンクされて示されることができる。選択された特性９０５は、例えば、虫垂切除術についてフィルタリングされた処置または手続でありえる。

第１の後続の選択された特性１２０６は、例えば、退院でありえる。第２の後続の選択された特性１２０８は、例えば、再入院でありえる。パターンフィルタ１２１０は、第１の後続の選択された特性１２０６および第２の後続の選択された特性１２０８のリターンを、特性の観察４０８の各インスタンスから３０日以内に制限するために含まれることができる。言い換えると、パターンフィルタ１２１０は、リターンされる図４のエンティティ４０４を、虫垂切除術を受けて退院し、退院後３０日以内に再入院したエンティティ４０４に制限することができる。

ここで図１３を参照すると、そこには、本発明の実施の形態に係る、リポートを生成するための例示的な制御フロー１３００が示されている。例示的な制御フロー１３００は、図２のリポートデータの定義１３０がどのようにして図１のスキーマ定義言語１２６に対して動作するのかについての例示的な説明でありえる。スキーマ定義言語１２６のメタデータ３０２は、図３のメタデータテーブル３００、図５のスキーマ定義モデルテーブル５００、図４のスキーマ定義モデル４００、またはそれらの組み合わせから参照されることができる。

図２のオペレーショナルデータストア２０６が一度ポピュレートされたときは、ユーザは、オペレーショナルデータストア２０６内の図４のエンティティ４０４のいずれかについてリポートすることができる。ユーザは、リターンされたリポートデータを定義することができる。図１のビジネスインテリジェンスツール１３４は、スキーマ定義言語１２６のメタデータ３０２を活用し、図４のエンティティ４０４、モジュール４０６、および特性の観察４０８の観点から定義されたリポートデータの定義１３０を構築する。ビジネスインテリジェンスツール１３４は、オペレーショナルデータストア２０６から図２のデータ２０３を抽出するためのリポートデータの定義１３０を実行し、１つ以上のスプレッドシートを通じてその結果を表す。ユーザは、図１５に関して以下詳細に説明されるさまざまなリポートビューワを通じてスプレッドシートデータを視て要約することもできる。

リポートデータの定義１３０は、リポート開始ステップ１３０２において始められる。リポート開始ステップ１３０２は、現在のコホート９１２を含み、これに対してリポートデータの定義１３０をおこなうことができる。図９のトータルコホート９０２、図１１の一致コホート１１２０、または図１１の不一致コホート１１２２さえも、リポートデータの定義１３０をおこなうために用いられることできる。

リポート開始ステップ１３０２から続くのは、データ定義ステップ１３０４である。データ定義ステップ１３０４は、リポートデータの定義１３０を含む。リポートデータの定義１３０は、どのエンティティ４０４および特性の観察４０８がリポート１３０８に含まれる予定であるかについて指定する。リポートデータの定義１３０は、デフォルトのエンティティ４０４とデフォルトの特性の観察４０８とを含む。デフォルトのエンティティ４０４は、現在のコホート９１２であり（または現在選択されているコホート）、一方でデフォルトの特性の観察４０８はエンティティ４０４のＩＤであり、特性の観察４０８は図９および１１に関し詳細に上述したようにエンティティ４０４を選択するために用いられる。

リポートデータの定義１３０が、特性の観察４０８およびエンティティ４０４とともに一度創作され定義されたときは、データ定義ステップ１３０４から続くオプション変更１３０９におけるリポートデータの定義１３０を変更するオプションをユーザは有する。ユーザが、リポートデータの定義１３０を変更することを望むときは、オプション変更１３０９から続くエンティティオプション変更１３１０または特性オプション変更１３１２が選択されることができる。

エンティティオプション変更１３１０または特性オプション変更１３１２がユーザに選択されたときは、スキーマ定義言語１２６はビジネスインテリジェンスツール１３４によって参照されることとなる。ユーザがリポートデータの定義１３０内でエンティティ４０４を変更することを選択したときは、ユーザはエンティティオプション変更１３１０を選択することとなる。

ユーザが、エンティティを追加することによってエンティティ４０４を変更することを決定したときは、参照ステップ１３１４は、スキーマ定義言語１２６を参照し、他のエンティティ４０４への図６のリンクのすべてを特定する。このことは、現在のコホート９１２のサブエンティティであるエンティティ４０４を追加する際に特に重要である。リンク６０８は、参照ステップ１３１４に続くリンクステップ１３１６において特定される。

リンク６０８が追加的なエンティティ４０４と前のエンティティ４０４との間で一度特定されたときは、図９のワンホップリンケージ９１４は計算ステップ１３１８において計算される。ワンホップリンケージ９１４は、新たに選択されたエンティティ４０４に対応する特性の観察４０８でありえる。つまり、ワンホップリンケージ９１４は、新たに選択されたエンティティ４０４が関連付けられた特性の観察４０８である。モジュール４０６は、ワンホップリンケージ９１４としてリターンされることもできる。新たに選択されたエンティティ４０４が、モジュール４０６またはエンティティ４０４によって指し示された場合、または代替的に、新たに選択されたエンティティ４０４が他のモジュール４０６またはエンティティ４０４を指し示したときは、これらの指し示されたモジュール４０６またはエンティティ４０４は、ワンホップリンケージ９１４としてリターンされることができる。

計算ステップ１３１８は、オプション１３２２を表示することができる表示ステップ１３２０へと続く。エンティティ４０４が添付、追加、またはリポートデータの定義１３０へリンクされたときは、ユーザはオプション１３２２を提供されることとなる。オプション１３２２は、最初、最後、またはすべての経年的なオプションを含む。オプション１３２２は、リポートに含まれる特性のタイプに基づくフィルタリングなどのフィルタリングのオプションをさらに含むことができる。フィルタリングのオプションは、フィルタ基準に一致する結果を維持するだけとなる。オプション１３２２は、制限的、非限定的などの制約のオプションをさらに含む。制約のオプションは、ＳＱＬ内部結合対外部結合と同等の意味である。

オプション１３２２が、ユーザに提供された後に、アップデートステップ１３２４はリポートデータの定義１３０を新たに要求されたエンティティ４０４と現在のコホート９１２へのリンク６０８とでアップデートする。特性の観察４０８をリポートデータの定義１３０に追加するときは、ビジネスインテリジェンスツール１３４は同様のフローを活用する。

リポート１３０８が特性オプション変更１３１２を表示することとなる特性の観察４０８を変更することをユーザが望む場合は、特性オプション変更１３１２が選択されることができる。ビジネスインテリジェンスツール１３４は、ユーザが追加したい特性の観察４０８が決定オプション１３２６内のリポートデータの定義１３０に現在存在するモジュール４０６に属しているか否かを判断することとなる。モジュール４０６が現在リポートデータの定義１３０の一部でないときは、参照ステップ１３１４は、スキーマ定義言語１２６を参照するために用いられる。リンク６０８がリンクステップ１３１６で計算され、最後にワンホップリンケージ９１４が計算ステップ１３１８で計算される。

ワンホップリンケージ９１４は、ユーザに追加された特性の観察４０８が対応するエンティティ４０４とモジュール４０６とに対応する他の選択されていない特性の観察４０８でありえる。つまり、ワンホップリンケージ９１４は、追加された特性の観察４０８が関連付けられた同じモジュール４０６とエンティティ４０４から追加されていない特性である。追加されていない特性の観察４０８と共に、計算ステップ１３１８はワンホップリンケージ９１４としてモジュール４０６とエンティティ４０４とをリターンすることもできる。選択された特性９０５と関連付けられたモジュール４０６とエンティティ４０４とが、他の関連付けられていないモジュール４０６とエンティティ４０４とによって指し示されたときは、これらの関連付けられていないモジュール４０６またはエンティティ４０４は、ワンホップリンケージ９１４としてリターンされることができる。つまり、いずれかの特性の観察４０８を有する図５の対象エンティティタイプ５１２または対象モジュールタイプ５１４が、ユーザに追加された特性の観察４０８に関連付けられたモジュール４０６またはエンティティ４０４へのデータポインタを含んでいるときは、このデータポインタを有する特性の観察４０８に関連付けられたモジュール４０６およびエンティティ４０４は、ワンホップリンケージ９１４としてリターンされることとなる。

直前に説明されたエンティティ４０４の追加と同様に、表示ステップ１３２０はユーザに対しオプション１３２２を表示する。エンティティ４０４とモジュール４０６を追加する際に表示されるオプション１３２２は同じでありえる。しかしながら、追加のオプションまたはエンティティ４０４かモジュール４０６に独自のオプションが異なるように表示され、追加されるものに依存して表示されることができる。

オプション１３２２がユーザに提供された後に、アップデートステップ１３２４は、新たに要求されたモジュール４０６と、それらの現在のコホート９１２へのリンク６０８と、その中のモジュール４０６とで、リポートデータの定義１３０をアップデートすることとなる。決定オプション１３２６が呼び起こされ、特性の観察４０８がリポートデータの定義１３０内ですでにモジュール４０６と関連付けられていると判断したときは、参照ステップ１３１４は、スキーマ定義言語１２６を単純に参照し、リンクステップ１３１６は特性の観察４０８をリポートデータの定義１３０に取り入れるために要求されるリンク６０８を特定する。

特性の観察４０８がリポートデータの定義１３０内ですでにモジュール４０６と関連付けられているときは、計算ステップ１３１８と表示ステップ１３２０は、ワンホップリンケージ９１４を計算するためまたはオプション１３２２を表示するために呼び起こされる必要はない。アップデートステップ１３２４は、リポートデータの定義１３０をアップデートし、ユーザにオプション変更１３０９をリターンするために呼び起こされることができる。

上記活用されたＩＣＤ９乳がんの例から続けると、ユーザは、分子実験に対応する品質に関する特性の観察４０８についてリポートを望むことがあり、モジュール４０６は現在のコホート９１２としてリターンされたがん患者の腫瘍サンプルエンティティ４０４について実行されるが、乳がんのタイプを示す特性の観察４０８によって階層化される。ここで、ユーザは、「Ｃｅｌファイル品質」と「トリプルネガティブ」という特性の観察４０８を、リポートデータの定義１３０に単純に追加する。スキーマ定義言語１２６は、Ｃｅｌファイル品質の特性の観察４０８を追加する際、乳がん診断の特性の観察４０８の腫瘍エンティティ４０４の診断へリンク６０８を提供するため、かつ、これらの腫瘍エンティティ４０４に対して実行される分子実験モジュールへも適切にリンクするために参照される。なぜなら、トリプルネガティブという特性の観察４０８は、リポートデータの定義１３０内にすでに含まれているがん診断モジュール４０６の一部だからである。

ユーザがリポートデータの定義１３０の変更をもはや望まないときは、ユーザは、オプション変更１３０９から続く実行ステップ１３２８内でリポートを実行してもよい。スキーマ定義言語１２６は、実行ステップ１３２８から続くスキーマ参照ステップ１３３０によるリポートデータの定義１３０内で、特性の観察４０８と、モジュール４０６と、エンティティ４０４とを含むオペレーショナルデータストア２０６内の物理テーブル２１８の位置を特定するために参照されることができる。

ＳＱＬ命令１３３２は、スキーマ参照ステップ１３３０から続くＳＱＬ生成ステップ１３３４によって自動的に生成されることができる。ＳＱＬ命令１３３２は、スキーマ参照ステップ１３３０から集められた情報に基づいて生成されることができる。なぜなら、物理テーブル２１８の位置と要求されたデータ２０３間のリンク６０８は、スキーマ定義言語１２６から特定されることができるからである。

ＳＱＬ命令１３３２がオペレーショナルデータストア２０６に対して一度実行されたときは、リポート１３０８は、ＳＱＬ生成ステップ１３３４に続く提示ステップ１３３６において、ユーザに対しスプレッドシートが提示されることができる。リポート１３０８は、提示ステップ１３３６に続く報告ステップ１３３８においてフィルタリングされ、表示され、分析されることができる。報告ステップ１３３８は、図１５に関し以下に詳細に説明される。

一例として、報告ステップ１３３８は、ピボットテーブル報告ツールを提供し、かつ、リポートデータの定義１３０で抽出されたデータ２０３を有するピボットテーブルの値と次元とをポピュレートするようユーザに促すことができる。

ここで図１４を参照すると、そこには、図１のビジネスインテリジェンスツール１２６において実現されたような図１のリポートデータの定義１３０のスクリーンショットが示されている。スクリーンショット１４００は、特性の観察４０８が関連付けられた特性２２２のサンプルを描いている。

デフォルトで含まれる特性の観察４０８は、患者ＩＤと図４のエンティティ４０４をフィルタリングするために用いられた特性の観察４０８とを含むことができる。説明的な一例として、スクリーンショット１４００においてデフォルトである特性の観察４０８は、患者ＩＤとＩＣＤ９である。

一時的なコホート１４０２のためのリポートを生成するために、ユーザは、分析のために含まれるべきである他の特性の観察４０８を選択してもよい。一例として、ユーザはＣｅｌファイル品質やトリプルネガティブを選択することができる。描かれているように、ビジネスインテリジェンスツール１２６は、新たに追加された特性の観察４０８に対応するエンティティ４０４を含むことができる。

Ｃｅｌファイル品質の特性の観察４０８のために、エンティティ４０４の実験およびサンプルは、対応する特性の観察４０８の実験ＩＤおよびサンプルＩＤと共に追加されることができる。さらに描かれているように、トリプルネガティブの特性の観察４０８は、デフォルトで含まれたモジュール４０６をすでに含んでいる。特に、がん診断は、ＩＣＤ９特性の観察４０８に対応するモジュール４０６としてすでに含まれていた。

ここで図１５を参照すると、そこには、本発明の実施の形態に係るリポートを解析するための制御フロー１５００が示されている。制御フロー１５００は、図１３のリポート１３０８を解析するための追加的なステップを含む図１３における前の制御フロー１３００からステップの一部を描いている。

描かれているように、リファインステップ１５０２は、データ引き出しステップ１５０４へと続くことができる。リファインステップ１５０２とデータ引き出しステップ１５０４とは、制御フロー１３００のステップからなることができる。例えば、リファインステップ１５０２は、図１のリポートデータの定義１３０をリファインまたは変更するために、図１３のデータ定義ステップ１３０４と、オプション変更１３０９と、エンティティオプション変更１３１０と、特性オプション変更１３１２と、参照ステップ１３１４と、リンクステップ１３１６と、計算ステップ１３１８と、表示ステップ１３２０と、アップデートステップ１３２４とからなる。

データ引き出しステップ１５０４は、リポート１３０８内で図２のデータ２０３を引き出してリポート１３０８をユーザに表示するために、図１３のステップ実行ステップ１３２８と、スキーマ参照ステップ１３３０と、ＳＱＬ生成ステップ１３３４とからなることができる。リポート１３０８がデータ引き出しステップ１５０４において一度引き出されたときは、データ引き出しステップ１５０４から続くツール選択ステップ１５０６において、分析ツール１５０８を選択するようユーザに促すことができる。

ツール選択ステップ１５０６は、次にあげる分析ツールを選択することができる。すなわち、ＡＮＯＶＡ（一元）ツール、ＡＮＯＶＡ（二元）ツール、分割ツール、コックス回帰ツール、コックス回帰（多制御変数）ツール、カプラン・メイヤーのツール（二つの日付）、Ｋ平均法クラスタリングツール、ＬｉＭＭＡツール、ロジスティック回帰ツール、マン・ホイットニーのツール、１標本ｔ検定ツール、および他の分析ツールである。分析ツール１５０８がツール選択ステップ１５０６において一度選択されたときは、図１のビジネスインテリジェンスツール１３４は分析ツール１５０８を実行するために要求される入力を選択するようユーザを促すことができる。入力は、ツール選択ステップ１５０６から続くプロンプトステップ１５１０内で要求されることができる。

ユーザが入力を一度定義すると、ユーザは、リポート１３０８からのデータ２０３をマップステップ１５１２における入力へマッピングする。データ２０３が分析ツール１５０８の入力へ一度マッピングされたときは、ビジネスインテリジェンスツール１３４は、分析を実行し、分析結果をユーザに表示する。上記ＩＣＤ９乳がんの例を続けると、仮にユーザが、患者エンティティ４０４に施された図４のさまざまな処置プロトコルの特性の観察４０８によってグループ分けされた、図４の乳がん患者エンティティ４０４に対して図４の生存期間の特性の観察４０８を比較し分析することを望んでいると仮定する。ユーザは、リポートデータの定義１３０をリファインして、分析を完全にするために要求される特性の観察４０８を含める。すなわち、診断時年齢の特性の観察４０８、生存期間の特性の観察４０８、処置プロトコルの特性の観察４０８、および患者が乳がんで亡くなったか否かを示すフラグの特性の観察４０８である。

リポート１３０８は、データ引き出しステップ１５０４において引き出される。ユーザは、その後、ツール選択ステップ１５０６において分析ツール１５０８であるコックス回帰を選択することができる。ユーザは、リポート１３０８からのデータ２０３をマッピングステップ１５１２における入力にマッピングし、分析を実行する。ビジネスインテリジェンスツール１３４は、分析をおこない、処置プロトコルの各組の統計的比較により戻されたビジュアルカプラン・マイヤー曲線などのさまざまな形式で、分析結果をユーザに提示する。

上記図面における制御フローとブロック図は、本発明のさまざまな実施の形態に係る構造および機能ならびに、システム、方法、コンピュータプログラム製品の実現可能なオペレーションを示す。この観点で、制御フローまたはブロック図における各ブロックは、特定の論理関数を実現するための１つ以上の実行可能な命令からなる、モジュール、セグメント、またはコードの部分を表してもよい。いくつかの代替的な実施の形態において、各ブロックに示された機能は図面に示された順番以外の順番で生じてもよいことにも留意すべきである。例えば、連続して示される２つのブロックは、実際、実質的に同時に実行されてもよく、または、当該ブロックは有する機能性次第で時折逆の順序で実行されてもよい。ブロック図および／またはフローチャート図の各ブロックと、ブロック図または／およびフローチャート図におけるブロックの組み合わせは、特定の機能または動作を実施する特殊目的のハードウェアに基づくシステムによってまたは特殊目的のハードウェアとコンピュータプログラムとの組み合わせによって実現されることができる。

有利なことに、本発明の実施の形態は、高いレベルで抽象化されたスキーマ定義言語を提供するため、かつオペレーショナルデータストアを低コストかつ短いタイムフレームで活用するためのビジネスインテリジェンスツールを実現可能にするためのスキーマ定義言語とのインターフェースとなるプラットフォームを提供するための技術を提供する。スキーマ定義言語は、ビジネスインテリジェンスツールが高い抽象化レベルで動作できるようにして、基礎となるデータベースが発展したときでもこれらのツールが変更される必要がないようにする。データベースは、本発明のスキーマ定義言語を活用する際、容易かつ妨害されることなく発展する。

生じるプロセスと構成は、分かりやすく、コスト対効果が高く、複雑でなく、非常に多目的で、正確で、センシティブで、効果的であり、また、容易に、効率的かつ経済的に適用し利用するための周知の部品を採用して実施されることができる。

上述の記載は本発明の実施の形態に関するが、本発明の基礎的な範囲から逸脱することなく、本発明の他のさらなる実施の形態が考案されることがあり、その範囲は後に続く請求項によって定められる。

したがって、本発明は、含まれたクレームの範囲内であるそのような代替、変更、および変形のすべてを包含すると意図される。ここに記載されまたは添付図面に示されたすべての事項は、説明的かつ非限定的な意味において解釈されるべきである。

Claims (20)

1. １以上のプロセッサが実行する方法であって、
   エンティティにリンクされた、前記エンティティについての観察可能な事実である特性の観察であって、メタデータと共にモジュールにおいてグループ分けされた前記特性の観察を定義するスキーマ定義言語を、コンピュータメモリから前記１以上のプロセッサが提供し、
   前記特性の観察ごとの行と、前記特性の観察がリンクされたエンティティのタイプを定義するエンティティタイプ及び前記特性の観察がリンクされたモジュールのタイプを定義するモジュールタイプの列とを有し、かつ前記メタデータを含むセルを有するスキーマ定義モデルテーブルを前記１以上のプロセッサが獲得し、
   オペレーショナルデータストアにおいて、前記特性の観察の少なくとも一つに基づいて、互いにリンクされた前記モジュールと前記エンティティのための別の物理テーブルであって、前記スキーマ定義モデルテーブル内の前記モジュールタイプごとに前記スキーマ定義モデルテーブルにおける前記特性の観察ごとの列を有する別の物理テーブルを前記１以上のプロセッサが生成し、
   前記メタデータにしたがって、前記別の物理テーブルにデータを前記１以上のプロセッサがポピュレートする方法。
2. 請求項１に係る方法であって、さらに、
   前記スキーマ定義言語のメタデータを参照して前記別の物理テーブル内で選択された特性の位置を特定し、かつ前記モジュールまたは前記エンティティのための別の物理テーブルが前記選択された特性を含んでいるか否かを前記１以上のプロセッサが判断する方法。
3. 請求項２に係る方法であって、さらに
   前記スキーマ定義言語のメタデータを参照して前記別の物理テーブルの位置を特定し、前記モジュールまたは前記エンティティのための前記別の物理テーブルが前記選択された特性を含んでいたときのみ、前記別の物理テーブルが後続の選択された特性を含んでいるか否かを前記１以上のプロセッサが判断する方法。
4. 請求項１に係る方法であって、さらに
   前記特性の観察が選択された特性と同じモジュール内にグループ分けされているときは、前記特性の観察がワンホップリンケージであると前記１以上のプロセッサが判断する方法。
5. 請求項１に係る方法であって、さらに
   選択された特性の臨床パターンが前記特性の観察に対応する場合、一致コホートに前記エンティティを前記１以上のプロセッサが分類し、
   選択された特性の臨床パターンが前記特性の観察に対応しない場合、不一致コホートとして前記エンティティを分類する方法。
6. 請求項１に係る方法であって、さらに
   前記モジュールがリポートデータの定義に関連付けられているか否かを前記１以上のプロセッサが判断し、
   前記モジュールがリポートデータの定義に関連付けられていないときは、前記スキーマ定義言語を前記１以上のプロセッサが参照する方法。
7. 請求項１に係る方法であって、
   前記別の物理テーブルに前記１以上のプロセッサがポピュレートすることは、前記スキーマ定義言語の前記メタデータを参照して前記データが前記特性の観察に適切なデータタイプであるか否かを前記１以上のプロセッサが判断することを含む方法。
8. プロセッサと関連して用いられるコンピュータで読み取り可能な非一時的な媒体であって、
   エンティティにリンクされた、前記エンティティについての観察可能な事実である特性の観察であって、メタデータと共にモジュールにおいてグループ分けされた前記特性の観察を定義するスキーマ定義言語を提供し、
   前記特性の観察ごとの行と、前記特性の観察がリンクされたエンティティのタイプを定義するエンティティタイプ及び前記特性の観察がリンクされたモジュールのタイプを定義するモジュールタイプの列とを有し、かつ前記メタデータを含むセルを有するスキーマ定義モデルテーブルを獲得し、
   オペレーショナルデータストアにおいて、前記特性の観察の少なくとも一つに基づいて、互いにリンクされた前記モジュールと前記エンティティのための別の物理テーブルであって、前記スキーマ定義モデルテーブル内の前記モジュールタイプごとに前記スキーマ定義モデルテーブルにおける前記特性の観察ごとの列を有する別の物理テーブルを生成し、
   前記メタデータにしたがって、前記別の物理テーブルにデータをポピュレートするよう構成された命令を含む媒体。
9. 請求項８に係るコンピュータで読み取り可能な非一時的な媒体であって、さらに
   前記スキーマ定義言語のメタデータを参照して前記別の物理テーブル内で選択された特性の位置を特定し、かつ前記モジュールまたは前記エンティティのための別の物理テーブルが前記選択された特性を含んでいるか否かを判断するよう構成された命令を含む媒体。
10. 請求項９に係るコンピュータで読み取り可能な非一時的な媒体であって、さらに
    前記スキーマ定義言語のメタデータを参照して前記別の物理テーブルの位置を特定し、前記モジュールまたは前記エンティティのための前記別の物理テーブルが前記選択された特性を含んでいたときのみ、前記別の物理テーブルが後続の選択された特性を含んでいるか否かを判断するよう構成された命令を含む媒体。
11. 請求項８に係るコンピュータで読み取り可能な非一時的な媒体であって、さらに
    前記特性の観察が選択された特性と同じモジュール内にグループ分けされているときは、前記特性の観察がワンホップリンケージであると判断するよう構成された命令を含む媒体。
12. 請求項８に係るコンピュータで読み取り可能な非一時的な媒体であって、さらに
    選択された特性の臨床パターンが前記特性の観察に対応する場合、一致コホートに前記
    エンティティを分類し、
    選択された特性の臨床パターンが前記特性の観察に対応しない場合、不一致コホートとして前記エンティティを分類するよう構成された命令を含む媒体。
13. 請求項８に係るコンピュータで読み取り可能な非一時的な媒体であって、さらに
    前記モジュールがリポートデータの定義に関連付けられているか否かを判断し、
    前記モジュールがリポートデータの定義に関連付けられていないときは、前記スキーマ定義言語を参照するよう構成された命令を含む媒体。
14. 請求項８に係るコンピュータで読み取り可能な非一時的な媒体であって、
    前記別の物理テーブルにポピュレートすることは、前記スキーマ定義言語の前記メタデータを参照して前記データが前記特性の観察に適切なデータタイプであるか否かを判断することを含むよう構成された命令を含む媒体。
15. エンティティにリンクされた、前記エンティティについての観察可能な事実である特性の観察であって、メタデータと共に、開始日と終了日とを含む記録の具体例であって前記特性の観察のひとつとなるモジュールにおいてグループ分けされた前記特性の観察を定義するスキーマ定義言語を、コンピュータメモリからプロセッサで提供し、
    前記特性の観察ごとの行と、前記特性の観察がリンクされたエンティティのタイプを定義するエンティティタイプ及び前記特性の観察がリンクされたモジュールのタイプを定義するモジュールタイプの列とを有し、かつ前記メタデータを含むセルを有するスキーマ定義モデルテーブルを獲得し、
    オペレーショナルデータストアにおいて、前記特性の観察の少なくとも一つに基づいて、互いにリンクされた前記モジュールと前記エンティティのための別の物理テーブルであって、前記スキーマ定義モデルテーブル内の前記モジュールタイプごとに前記スキーマ定義モデルテーブルにおける前記特性の観察ごとの列を有する別の物理テーブルを生成するよう構成され、
    前記メタデータにしたがって、前記別の物理テーブルにデータをポピュレートする、１以上のプロセッサを備えるシステム。
16. 請求項１５に係るシステムであって、
    前記１以上のプロセッサは、前記スキーマ定義言語のメタデータを参照して前記別の物理テーブル内で選択された特性の位置を特定し、かつ前記モジュールまたは前記エンティティのための別の物理テーブルが前記選択された特性を含んでいるか否かを判断するよう構成されているシステム。
17. 請求項１６に係るシステムであって、
    前記１以上のプロセッサは、前記スキーマ定義言語のメタデータを参照して前記別の物理テーブルの位置を特定し、前記モジュールまたは前記エンティティのための前記別の物理テーブルが前記選択された特性を含んでいたときのみ、前記別の物理テーブルが後続の選択された特性を含んでいるか否かを判断するよう構成されているシステム。
18. 請求項１５に係るシステムであって、
    前記１以上のプロセッサは、前記特性の観察が選択された特性と同じモジュール内にグループ分けされているときは、前記特性の観察がワンホップリンケージであると判断するよう構成されているシステム。
19. 請求項１５に係るシステムであって、
    前記１以上のプロセッサは、
    選択された特性の臨床パターンが前記特性の観察に対応する場合、一致コホートに前記
    エンティティを分類し、
    選択された特性の臨床パターンが前記特性の観察に対応しない場合、不一致コホートとして前記エンティティを分類するよう構成されているシステム。
20. 請求項１５に係るシステムであって、
    前記１以上のプロセッサは、
    前記モジュールがリポートデータの定義に関連付けられているか否かを判断し、
    前記モジュールがリポートデータの定義に関連付けられていないときは、前記スキーマ定義言語を参照するよう構成されているシステム。

Images