(57)【特許請求の範囲】
【請求項１】
少なくとも１つの第１の健康管理データベースにおいて識別される個人に対応付けられる一意のエイリアスを生成するための方法であり、前記第１の健康管理データベースは、複数の識別フィールドと、前記個人に対応付けられた健康管理データを含む１つの健康管理フィールドとを有する、少なくとも１つのレコードを格納する第１のデータ記憶装置を含み、
前記方法は、コンピュータシステムによって実行され、
（ａ）前記第１の健康管理データベースの前記第１のデータ記憶装置内の、第１の複数の識別フィールドと前記個人に対応付けられた第１の健康管理フィールドとを含む第１のレコード、を選択するステップと、
（ｂ）前記第１のレコード内の前記第１の複数の識別フィールドの第１のサブセットを選択するステップと、
（ｃ）前記選択された識別フィールドの第１のサブセットを使用して第１の連結された識別子を生成するステップと、
（ｄ）前記第１の連結された識別子の少なくとも１部を暗号化することにより第１の一意のエイリアスを規定するステップと、
（ｅ）前記第１の複数の識別フィールドを除いて、前記第１の一意のエイリアスと前記第１の健康管理フィールドを、選択的に処理してデータセットとする複数の健康管理フィールドを含む第２のデータ記憶装置内に記憶するステップと、
（ｆ）前記データセットから構成されるレポートを生成するステップと、
を有することを特徴とする方法。
【請求項２】
前記選択された第１のサブセットは、少なくとも姓、誕生日、および性別を含む、請求項１に記載の方法。
【請求項３】
前記健康管理データは、少なくとも医薬請求データ、診療請求データ、あるいは入院請求データを含む、請求項１に記載の方法。
【請求項４】
（ａ）前記第１の一意のエイリアスと前記第１の健康管理フィールドとを受信し、（ｂ）前記第１の一意のエイリアスと前記第１の健康管理フィールドとを前記第2のデータ記憶装置に記憶する、請求項１に記載の方法。
【請求項５】
前記第１の健康管理フィールドを、前記第１の一意のエイリアスを用いて１以上の他のレコードから得られた少なくとも１つの健康管理フィールドとリンクすることによって、リンクされた複数の健康管理フィールドを生成する、請求項４に記載の方法。
【請求項６】
前記リンクされた複数の健康管理フィールドを用いてマーケット分析を行う、請求項５に記載の方法。
【請求項７】
前記リンクされた複数の健康管理フィールドを用いて医薬分析を行う、請求項５に記載の方法。
【請求項８】
前記リンクされた複数の健康管理フィールドを用いて診療状態分析を行う、請求項５に記載の方法。
【請求項９】
前記リンクされた複数の健康管理フィールドを用いて患者分析を行う、請求項５に記載の方法。
【請求項１０】
（ａ）前記個人に対応付けられた健康管理レコードから得られた暗号化され連結された識別フィールドのサブセットを含む第２の一意のエイリアスと、第２の健康管理フィールドとを受信し、（ｂ）前記第２の一意のエイリアスと、前記第２の健康管理フィールドとを前記第２のデータ記憶装置に記憶する、請求項５に記載の方法。
【請求項１１】
前記第１の一意のエイリアスと前記第２の一意のエイリアスとを使用して前記第１の健康管理フィールドを前記第２の健康管理フィールドとリンクする、請求項１０に記載の方法。
【請求項１２】
第２の健康管理データベースにおいて識別される個人に対応付けられる一意のエアリアスを生成するステップを有し、前記第２の健康管理データベースは、複数の識別フィールドと、前記個人に対応付けられた健康管理データを含む１つの健康管理フィールドとを有する、少なくとも１つのレコードを格納する第１のデータ記憶装置を含み、
前記第２の健康管理データベースにおいて識別される個人に対応付けられる一意のエアリアスを生成するステップは、
（ａ）前記第２の健康管理データベースの第１のデータ記憶装置内の、第２の複数の識別フィールドと前記個人に対応付けられた第２の健康管理フィールドとを含む第２のレコードを選択し、
（ｂ）前記第２のレコード内の前記第２の複数の識別フィールドの第２のサブセットを選択し、
（ｃ）前記選択された識別フィールドの第２のサブセットを使用して第２の連結された識別子を生成し、
（ｄ）前記第２の連結された識別子の少なくとも１部を暗号化することにより第２の一意のエイリアスを規定し、
（ｅ）前記第２の複数の識別フィールドを除いて、前記第２の一意のエイリアスと前記第２の健康管理フィールドを前記第２のデータ記憶装置内に記憶する、
請求項１に記載の方法。
【請求項１３】
（ａ）前記第１の一意のエイリアスと前記第１の健康管理フィールドとを受信し、
（ｂ）前記第１の一意のエイリアスと前記第１の健康管理フィールドとを前記第２のデータ記憶装置に記憶し、
（ｃ）前記第２の一意のエイリアスと前記第２の健康管理フィールドとを受信し、
（ｄ）前記第２の一意のエイリアスと前記第２の健康管理フィールドとを前記第２のデータ記憶装置に記憶する、
請求項１２に記載の方法。
【請求項１４】
前記第１の一意のエイリアスと前記第２の一意のエイリアスを用いて、前記第１の健康管理フィールドを前記第２の健康管理フィールドとリンクすることによって、リンクされた第１および第２の健康管理フィールドを生成する、請求項１３に記載の方法。
【請求項１５】
前記リンクされた第１および第２の健康管理フィールドを用いてマーケット分析を行う、請求項１４に記載の方法。
【請求項１６】
前記リンクされた第１および第２の健康管理フィールドを用いて医薬分析を行う、請求項１４に記載の方法。
【請求項１７】
前記リンクされた第１および第２の健康管理フィールドを用いて診療状態分析を行う、請求項１４に記載の方法。
【請求項１８】
前記リンクされた第１および第２の健康管理フィールドを用いて患者分析を行う、請求項１４に記載の方法。
【請求項１９】
少なくとも１つの第１の健康管理データベースにおいて識別される個人に対応付けられる一意のエイリアスを生成するための方法であり、前記第１の健康管理データベースは、複数の識別フィールドと前記個人に対応付けられた健康管理データを含む１つの健康管理フィールドとを有する、少なくとも１つのレコードを格納する第１のデータ記憶装置を含み、
前記方法は、コンピュータシステムによって実行され、
（ａ）前記第１の健康管理データベースの前記第１のデータ記憶装置内の、第１の複数の識別フィールドと前記個人に対応付けられた第１の健康管理フィールドとを含む第１のレコードを選択し、
（ｂ）前記第１のレコード内の前記第１の複数の識別フィールドの第１のサブセットを選択し、
（ｃ）前記選択された識別フィールドの第１のサブセットを使用して第１の連結された識別子を生成し、
（ｄ）前記第１の連結された識別子の少なくとも１部を暗号化することにより第１の一意のエイリアスを規定し、
（ｅ）前記第１の一意のエイリアスを使用して、前記第１の健康管理フィールドを１以上の他のレコードから得られる複数の健康管理フィールドとリンクし、
（ｆ）少なくとも１つのレコードと１以上の他のレコードを選択的に収集し、前記少なくとも１つのレコードと前記１以上の他のレコードを選択的に処理してデータセットとし、
（ｇ）前記データセットを表示することによりレポートを生成する、
ことを特徴とする方法。
【請求項２０】
複数の健康管理データベースにおいて識別される個人に対応付けられる一意のエイリアスを使用するための方法であり、各健康管理データベースが、複数の識別フィールドと前記個人に対応付けられた健康管理データを含む１つの健康管理フィールドとを有する、少なくとも１つのレコードを格納する第１のデータ記憶装置を含み、
前記方法は、コンピュータシステムによって実行され、
（ａ）次のステップ、
ｉ．第１の健康管理データベースの第１のデータ記憶装置内の、第１の複数の識別フィールドと前記個人に対応付けられた第１の健康管理フィールドとを含む第１のレコードを選択するステップと、
ｉｉ．前記第１のレコード内の前記第１の複数の識別フィールドの第１のサブセットを選択するステップと、
ｉｉｉ．前記選択された識別フィールドの第１のサブセットを使用して第１の連結された識別子を生成するステップと、
ｉｖ．前記第１の連結された識別子の少なくとも１部を暗号化することにより前記第１の一意のエイリアスを生成するステップと、
を実行することによって生成された第１の一意のエイリアスと、第１の健康管理フィールドとを受信し、
（ｂ）次のステップ、
ｉ．第２の健康管理データベースの第１のデータ記憶装置内の、第２の複数の識別フィールドと前記個人に対応付けられた第２の健康管理フィールドとを含む第２のレコードを選択するステップと、
ｉｉ．前記第２のレコード内の前記第２の複数の識別フィールドの第２のサブセットを選択するステップと、
ｉｉｉ．前記選択された識別フィールドの第２のサブセットを使用して第２の連結された識別子を生成するステップと、
ｉｖ．前記第２の連結された識別子の少なくとも１部を暗号化することにより前記第２の一意のエイリアスを生成するステップと、
を実行することによって生成された第２の一意のエイリアスと、第２の健康管理フィールドとを受信し、
（ｃ）前記第１の一意のエイリアスと前記第２の一意のエイリアスとを使用して前記第１の健康管理フィールドを前記第２の健康管理フィールドとリンクするステップと、
（ｄ）前記第１の健康管理フィールドと前記第２の健康管理フィールドを選択的に収集し、前記第１の健康管理フィールドと前記第２の健康管理フィールドを選択的に処理してデータセットとするステップと、
（ｅ）前記データセットを表示することによりレポートを生成するステップと、
を有することを特徴とする方法。
【請求項２１】
健康管理データベースにおいて識別される個人に対応付けられる一意のエイリアスを生成するためのシステムであり、
（ａ）互いに異なる場所に配置された複数の第１のデータ記憶装置であって、各第１の記憶装置は複数のレコードを記憶し、各レコードが、ひとまとめにされると一意に個人を識別する複数の識別フィールドと、前記個人に対応付けられた健康管理データに該当する少なくとも１つの健康管理フィールドとを含む、複数の第１のデータ記憶装置と、
（ｂ）第１のデータ記憶装置から選択された複数のレコードを有するファイルを生成する、各第１のデータ記憶装置に対応付けられた手段と、
（ｃ）（ｉ）前記ファイルのレコードを選択するステップと、
（ｉｉ）前記選択されたレコード内の前記複数の識別フィールドのサブセットを選択するステップと、
（ｉｉｉ）前記選択された識別フィールドのサブセットを連結するステップと、
（ｉｖ）前記連結された識別フィールドを暗号化して、一意のエイリアスを規定するステップと、
（ｖ）個人を一意に識別する前記ファイルのフィールドを前記一意のエイリアスで置換し、個人を一意に識別するファイルの残っているフィールドを削除するステップと、
（ｖｉ）前記複数のレコードを選択的に収集し、前記複数のレコードを選択的に処理してデータセットとするステップと、
（ｖｉｉ）前記データセットを表示することによりレポートを生成するステップと、
を実行する複数のプロセッサであって、各プロセッサが前記複数の第１のデータ記憶装置の１つに対応付けられている複数のプロセッサと、
を備えるとするシステム。
【請求項２２】
前記複数のデータ記憶装置の１以上の記憶装置に記憶された前記健康管理データは、医薬請求データ、診療請求データ、および入院請求データに該当する、請求項２１に記載のシステム。
【請求項２３】
前記選択されたサブセットは、姓、誕生日、および性別を含む、請求項２１に記載のシステム。
【請求項２４】
健康管理データベースにおいて識別される個人に対応付けられる一意のエイリアスを生成するためのシステムであり、前記健康管理データベースは、互いに異なる場所にある複数の第１のデータ記憶装置を含み、各第１のデータ記憶装置は複数のレコードを記憶し、各レコードが、ひとまとめにされると一意にある個人を識別する複数の識別フィールドと、前記個人に対応付けられる健康管理データに該当する少なくとも１つの健康管理フィールドとを含み、
前記システムは、
（ａ）前記複数の識別フィールドのサブセットを選択する、各第１のデータ記憶装置に対応付けられた手段と、
（ｂ）前記選択された複数の識別フィールドのサブセットを連結する、各第１のデータ記憶装置に対応付けられた手段と、
（ｃ）前記連結識別フィールドを暗号化して、一意のエイリアスを規定する、各第１のデータ記憶装置に対応付けられた手段と、
（ｄ）前記第１のデータ記憶装置の前記選択されたレコードから得られた少なくとも１つの健康管理フィールドを前記一意のエイリアスとともにファイルのレコードに記憶し、個人を一意に識別する前記ファイルのフィールドを除去する、各第１のデータ記憶装置に対応付けられた手段と、
（ｅ）レコードを選択的に収集し、前記レコードを選択的に処理してデータセットとすることに対応付けられた手段と、
（ｆ）前記データセットを表示することによりレポートを生成することに対応付けられた手段と、
を備えるシステム。
【請求項２５】
互いに異なる場所に配置された複数の健康管理データベースの１つにおいて識別される個人に対応付けられる一意のエイリアスを生成するための方法であり、各健康管理データベースは複数のレコードを記憶し、各レコードが、ひとまとめにされると一意にある個人を識別する複数の識別フィールドと、前記個人に対応付けられる健康管理データに該当する少なくとも１つの健康管理フィールドとを含み、
前記方法は、コンピュータシステムによって実行され、
（ａ）前記複数の健康管理データベースの１つのデータベース内のレコードを選択するステップと、
（ｂ）前記選択されたレコード内の前記複数の識別フィールドのサブセットを選択するステップと、
（ｃ）前記選択された識別フィールドのサブセットを連結するステップと、
（ｄ）前記連結された識別フィールドを暗号化して、一意のエイリアスを規定するステップと、
（ｅ）前記選択されたレコードから得られた少なくとも１つの健康管理フィールドを前記一意のエイリアスとともにファイルのレコードに記憶し、個人を一意に識別する前記ファイルのフィールドを削除するステップと、
（ｆ）レコードを選択的に収集し、前記レコードを選択的に処理してデータセットとするステップと、
（ｇ）前記データセットを表示することによりレポートを生成するステップと、
を含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的に言って、コンピュータ・システム及びデータベースに関するものである。より明確に言うと、本発明は、健康管理関連のデータの収集及び分析、特に個人による医薬使用に関する情報の収集及び分析に関するものである。本発明は、また、プライバシーの保護のために前記の医薬データから個人を匿名化するための技法に関するものである。
【０００２】
本出願は、1999年9月20日に提出された米国仮出願第60/154,726号（その全体が参照により本出願に組み込まれる）の恩典を請求する。
【背景技術】
【０００３】
医療情報の分野において、医薬請求は、1つまたはそれ以上の投薬処方を受け、保険会社または政府機関から請求の支払いを受けるために保険会社（または政府機関）に請求を提出した患者について請求データを受け取る大型コンピュータ・システムにおいて処理される。請求データは、請求を行なう個人に関する非常に具体的な詳細及び属性を含む。例えば、属性には、氏名、性別、生年月日、住所、医学診断、処方された特定の薬、及び患者が使用しているその他の薬が含まれうる。従って、このデータは、特定の薬の使用に関するマーケティング・リサーチに役立て、この使用に影響を与える様々な属性を特定するのに非常に有益である。
【０００４】
請求データは、一般に、データ「情報センター」で受け取られる。これは、特定の保険会社のデータベースであったり、あるいは多くの保険会社に請求処理サービスを提供するもっと大型のデータベースであったりする。さらに、請求者によって提出される請求データは、相当量のデータを含み、毎月システムには数百万件の新たな請求が入力される。請求データ情報センターの一部はテラバイト単位の請求データを処理するシステムを有する。提出されるデータのサイズが大きく、属性は多量なので、データは、特定の属性を効率よく探索、検索および分析するには不適切な形式である。
【０００５】
最近、医療請求データの中の個人に対応付けられる個人情報の伝送を防止する法律が議会を通過した。この法律は、特に、氏名、住所及び社会保障番号など特定の個人データの転送を禁止している。従って、請求データは、もはや、個人データを含む生データの形で情報センターから他者に伝送することは許されない。請求データを区別する個人情報無しでは、年齢、性別及び地理的分布など特定の個人の固有の属性に基づく貴重なリサーチ及びマーケット・データを生成することはずっと困難になる。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
従って、製薬業界に影響を及ぼすリサーチ及び分析を可能にするために複数の請求データベースから効率よく情報を収集するための能力を提供することが望ましい。従って、本発明は、主に、上に論じられる問題及び先行技術の関連する限界を克服するためのシステム及び方法に対処する。
【課題を解決するための手段】
【０００７】
1つの実施態様において、本発明は、マーケティング・リサーチのために区別されたデータの集計を可能にする、健康管理データベースにおいて識別される個人に対応付けられる一意のエイリアスを生成するためのシステム及び方法を提供する。このシステムは、少なくとも1つのレコードを記憶するための第一のデータ記憶装置を含むことができ、各レコードは、連結されると一意にある個人を識別する氏名及び生年月日など複数の識別フィールド、及び投薬タイプなどこの個人に対応付けられる健康管理データに該当する少なくとも1つの健康管理フィールドを有する。このシステムは、また、第二の記憶装置及びプロセッサを備え、該プロセッサは、第一のデータ記憶装置の1つのレコードを選択し、選択されたレコード内の前記の複数の識別フィールドのサブセットを選択し、選択された識別フィールドのサブセットを連結して、第一のデータ記憶装置の選択されたレコードからの少なくとも1つの健康管理フィールドと一緒に前記の連結された識別フィールドを第二のデータ記憶装置のレコードに記憶することもできる。第一のデータ記憶装置及び第二のデータ記憶装置は、同じデータベース内に配置するか、別個のデータベースに配置することができる。
【０００８】
第一のデータ記憶装置内に記憶される健康管理データは、1つの実施態様においては、医薬請求データに該当する。選択されたサブセットは、健康管理データベースの中の特定の個人に関するものであり、この個人の姓、誕生日及び性別は連結されてそのレコードの一意の識別子を形成する。プロセッサは、第二のデータ記憶装置の各レコードの連結された識別フィールド及び少なくとも1つの健康管理フィールドに基づき個人レベルのリンク方法を使って個人の長期的履歴レコードを分析することができる。健康管理データは、また、医学的に重要な情報のみが残るように個人データを各種のレコードから除去することができ、識別子は、個々のレコードが識別可能であるように医療情報を区別できるようにする。
【０００９】
健康管理レコードの膨大な量のデータをより効率よく処理するために、プロセッサは、さらに第一のデータ記憶装置からレコードを選択的に収集し、このレコードを選択的に処理してデータ・キューブにするステップを実施することができる。第一のデータ記憶装置のレコードは一般にテーブル形式であり、このレコードを処理するプロセスは、第一のデータ記憶装置の様々なテーブル形式レコードからレコードを結合し投影して、最終的にレコードのテーブルから成るデータ・キューブを構成する。データ・キューブ・フォーマットは、プロセッサが健康管理レコードをより容易に検索できるようにし、特定のデータ・キューブのレコードを表示することによってレポートを生成できるようにする。
【００１０】
本発明は、従って、健康管理データベースにおいて識別される個人に対応付けられる一意のエイリアスを生成するための方法を提供するものであり、この方法において、健康管理データベースは少なくとも1つのレコードを記憶し、各レコードは、ひとまとめにされると一意に個人を識別する複数の識別フィールドを有し、少なくとも1つの健康管理フィールドはこの個人に対応付けられる健康管理データに該当する。この方法は、健康管理データベース内の1つのレコードを選択するステップ、選択されたレコード内の前記の複数の識別フィールドのサブセットを選択するステップ、選択された識別フィールドのサブセットを連結するステップ、及び第一のデータ記憶装置の選択されたレコードからの少なくとも1つの健康管理フィールドと一緒に前記の連結された識別フィールドを第二のデータベースのレコードに記憶するステップを含む。この方法は、第二のデータベースの各レコードの連結された識別フィールド及び少なくとも1つの健康管理フィールドに基づき個人レベル・リンク方法を使って個人の長期的履歴レコードを分析するステップを含むことが望ましい。
【００１１】
健康管理データベース内のレコードを選択するステップは、医薬請求データからレコードを選択するステップを含むことができる。さらに、選択された識別フィールドのサブセットを連結するステップは、例えば、健康管理データベースの中の特定の者について、その者の姓、誕生日及び性別を連結するステップを含むことができる。このように、この方法は、第二のデータ記憶装置の各レコードの連結された識別フィールド及び少なくとも1つの健康管理フィールドに基づいて、個人レベル・リンク方法を使用して個人の長期的履歴レコードを分析するステップを含むことができる。
【００１２】
上で論じた通り、この方法は、さらに、第一のデータ記憶装置から選択的にレコードを収集するステップ及びレコードを選択的に処理してデータ・キューブにするステップを含むことができる。健康管理データベース内のレコードを選択するステップは、テーブル形式の第一のデータレコード装置のレコードを選択するステップを含むことができ、レコードを選択的に処理してデータ・キューブにするステップは、第一のデータ記憶装置から選択的にレコードを結合し投影してレコードのテーブルを含むデータ・キューブを生成するステップを含むことができる。
【００１３】
データ・キューブは、本発明のシステムが、全ての新規のレコードを掲示後すぐに調べることができるように効率的なフォーマットでレコードを集計できるようにする。さらに、一意の母集団識別子によって、ユーザは時間を追って患者を追跡することができ、患者の薬切り替え行動など他のデータベースにおいては入手できない重要な結果を生じる。患者レベルの医療トランザクション及び医薬トランザクションをリンクすることによって、薬の特異適応使用及び患者の合併疾患など新たな病識を決定できる。
【発明の効果】
【００１４】
システムによって表示されるレポートは、次のようないくつもの属性を含むことができる：国、地方、州及びMSAレベルでの地理的マーケット・シェア情報：年間、四半期、月間及び週間を含めた時間枠の動向：合計、新規及び補充処方カウントなど伝統的尺度：新規処方開始、切り替え及び継続患者などビジネス・ソース：処方者の専門分野：年齢及び性別別の患者人口統計：特異適応使用：及び患者合併疾患。システムは、従って、新しい薬の発売及び販売キャンペーンの監視、強化販売目標設定、選択された地域でのミクロマーケティングなど事業上の決定に役立てるために、または顧客を選択するために、多様な方法で使用することができる。さらに、このシステムは、特異適応製品の位置づけ、早期警戒マーケット・シェア変動、臨床試験現場選択、研究者採用、及び市場規模及び需要に関する正確な理解力を含めて、医薬マーケティング戦略の予測及び開発に使用することができる。
【図面の簡単な説明】
【００１５】
【図１Ａ】1つの実施態様における本発明の全体構造及び全体的流れを示すブロック及びフロー図である。
【図１Ｂ】1つの実施態様における本発明の全体構造及び全体的流れを示すブロック及びフロー図である。
【図１Ｃ】1つの実施態様における本発明の全体構造及び全体的流れを示すブロック及びフロー図である。
【図１Ｄ】1つの実施態様における本発明の全体構造及び全体的流れを示すブロック及びフロー図である。
【図１Ｅ】1つの実施態様における本発明の全体構造及び全体的流れを示すブロック及びフロー図である。
【図２Ａ】1つの実施態様における本発明の全体構造及び全体的流れを示すブロック及びフロー図である。
【図２Ｂ】1つの実施態様における本発明の全体構造及び全体的流れを示すブロック及びフロー図である。
【図２Ｃ】1つの実施態様における本発明の全体構造及び全体的流れを示すブロック及びフロー図である。
【図３Ａ】本発明の全体的流れ及びデータの関係を示すフローおよび関係図である。
【図３Ｂ】本発明の全体的流れ及びデータの関係を示すフローおよび関係図である。
【図４】本発明のデイリーRxロード・プロセスの動作を示す図である。
【図５】本発明のマンスリーMxロード・プロセスの動作を示す図である。
【図６】本発明のマンスリーHxロード・プロセスの動作を示す図である。
【図７】本発明のクォーター・マンスリー（1/4ヶ月）Rxマージ・プロセスの動作を示す図である。
【図８】本発明のMxデータ準備プロセスの動作を示す図である。
【図９】本発明の患者データ生成プロセスの動作を示す図である。
【図９Ａ】本発明のRSTRANSFORMERプロセスの動作を示す図である。
【図１０】本発明のキューブ・データ引き出しプロセスの動作を示す図である。
【図１１Ａ】本発明のTCキューブ・データ生成プロセスの動作を示す図である。
【図１１Ｂ】本発明のTCキューブ・データ生成プロセスの動作を示す図である。
【発明を実施するための形態】
【００１６】
本発明のその他の目的、特徴及び利点は、下記の図面、発明の詳細な説明及び特許請求の範囲から明らかになるだろう。
【００１７】
図面（図面全体を通じて同様の番号が同様の要素を表す）を参照すると、図1A、1B及び2は、本発明の高レベル結合ブロック/フロー図を示している。これらの図は、本発明のブロック図の要素並びに本発明のシステムが実行するステップの両方を表している。
【００１８】
図1A、1Bおよび2を参照すると、本発明において行なわれる主要な処理は、例えば、Sun Microsystems ES10000コンピュータ（SITE 2）などの高性能計算システムによって行なうことができる。毎日、1週間に７日、周期的に、SITE 1の計算システムは、ステップ103で医療請求データを安全な接続190を通じてSITE 1のコンピュータ・システムに送る。この医療請求データは、例えば、ステップ102で「匿名化」された（これについては下で詳しく説明する）医薬、医療および病院請求101を含むことができる。
【００１９】
請求データは、SITE 2に送られる前にステップ102で匿名化される。匿名化は、一意の識別子の応用、この識別子の暗号化及び特定の患者識別フィールドの除去を含む。データは、次にステップ104で同じくSITE 2に常駐するデータベース・テーブル（オラクル・データベースなど）にロードされる。ステップ105で、SITE 2は、データを分析し統合するため及びその結果のオラクル・テーブルをOLAPキューブに変換するための全てのプロセスを実行する。
【００２０】
キューブ構築プロセスは、別のコンピュータ（SITE 2など）で実行することができる。キューブは、例えばWindows（登録商標） NTオペレーティング・システムで動作するデスクトップ・コンピュータ上でOLAP製品を使ってモデリングされる。
【００２１】
キューブ配備プロセスは、別のコンピュータ（SITE 3など）で実行することができる。SITE 2の計算システムは、ステップ106でキューブおよびメタデータ・ファイルを安全な接続を通じてSITE 3に送る。キューブをプロダクションウェブサイトに置いて、関連メタデータでウェブサイト・ページを更新するために、SITE 3でステップ107のプロセスが実行される。
【００２２】
SITE 1のコンピュータからデータを入手し、キューブ・トランスフォーマ用にデータを準備し、これをSITE 3のウェブに表示した後SITE 2で実施されるプロセスは、論理的に、図3に示される通り、大きく下記の6つのステップに分けることができる：
1.  オラクル・テーブルのロード（ステップ301）
2.  患者データ生成（ステップ302）
3.  キューブ・データ引き出し（ステップ303）
4.  キューブ・データ生成（ステップ304）
5.  キューブ構築（ステップ305）
6.  自動キューブ配備及びメタデータ更新プロセス
【００２３】
上記の全てのプロセスは、定期的に、1日、1週および1月ごとに処理され、維持され、実行される。DOI、郵便番号-州-地方、IDC9などのテーブルの生成などルーチン・プロセス以外で行なわれるプロセスがいくつかある。図3は、キューブを生成するために使用されるプロセスの高レベルの概要を示す。
【００２４】
1.  オラクル・テーブルのロード（ステップ301）
オラクル・テーブル・ロード・プロセス（ステップ301）は、図4-8を参照して下で詳しく説明する通り、論理的に異なる2つのステップ、すなわちデイリー・プロセス及びマンスリー・プロセスに分けることができる。デイリー・ルーチンは、SITE 1から供給されるテキスト・フォーマットのデータを“RX”及び「社名使用禁止（DNU）」デイリー・オラクル・テーブルに変換する。マンスリー・プロセスは、病院（HX）及び医療（MX）データをマンスリー・オラクル・テーブルに変換する。下に示される実行時間は全て近似実行時間に該当することに留意すること。
【００２５】
1.1  デイリーRxロード・プロセス401
デイリーRXロード・プロセス401について、図4を参照しながら下に説明する：
スクリプト使用法：loaddaily.shは、必要な全ての番号、文字及び日付変換を行なった後にSITE 1からのRxテキスト・ファイルをLOAD_YYYYMMDD、｛DNU｝_YYYY MMDDオラクル・テーブルに変換するためにSQLローダRx制御ファイルを使用するUNIX（登録商標）シェル・スクリプトである。｛DNU｝リストは、BLUFFCREEK、KROGER、OMNI、PCN、VIP及びWALGREENを含んでいる。
【００２６】
【表１】
0005155429.tif 000002
【００２７】
1.2  マンスリーMxロード・プロセス501
マンスリーMxロード・プロセス501について、図5を参照しながら下に説明する：
スクリプト使用法：SQL LOADERプロセスは、MXDaily.MMDDYYテキスト・ファイル及び制御ファイルを読み取り、これをLOAD_MX_YYYYMMテーブルに変換する。
【００２８】
【表２】
0005155429.tif 000003
【００２９】
1.3  HXテキスト・データのロード601
HXテキスト・データ・ロード・プロセス601について、図6を参照しながら下に説明する：
スクリプト使用法：SQL LOADERプロセスは、HXテキスト・ファイル及び制御ファイルを読み取り、これをWH_ENVOY_HX_SE99テーブルに変換する。
【００３０】
【表３】
0005155429.tif 000004
【００３１】
1.4  クォーター・マンスリーRxマージ701
クォーター・マンスリーRxマージ・プロセス701について、図7を参照しながら下に説明する：
スクリプト使用法：このプロセスは、RX_Weekly_New.sql SQLスクリプトを使って、全てのデイリー（約8日分のテーブル）RX及びDNUテーブルを結合してクォーター・マンスリー・テーブルにする。
【００３２】
【表４】
0005155429.tif 000005
【００３３】
1.5  MXデータ準備（801）
Mxデータ準備プロセス801について、図8を参照しながら下に説明する：
スクリプト使用法：このプロセスは、Process_Monthly_MX.sql SQLスクリプトを使って、LOAD_MX_YYYYMMテーブル・データを確認して、これを要求される日付、文字及び番号に変換する。
【００３４】
【表５】
0005155429.tif 000006
【００３５】
2.  患者データ生成（ステップ302）
ステップ302（図3）の患者データ生成プロセスについて、図9を参照しながら下に詳しく説明する。
スクリプト使用法：このプロセスはMaster_PXpgmvlb_9910.sql SQLスクリプトを使って、ウィークリーRX及びマンスリーMX、HXテーブルを結合して、関係WHREF_ENVOY_PXYYMMテーブルを生成する。
【００３６】
【表６】
0005155429.tif 000007
【００３７】
3.  キューブ・データ引き出し（ステップ303）
ステップ303（図3）の患者データ生成プロセスについて、図10を参照しながら下に詳しく説明する：
【００３８】
このプロセスは、一連のオラクル記憶プロシージャを使って、エラー・チェック及び監査ログを可能にする。このプロシージャ用のログはMM_LOGテーブルを使用する。これらの記憶されたプロシージャは、必要な変数値を入力するシェル・スクリプト・ラッパを使用してUnix（登録商標）シェルから呼び出される。使用される記憶済みプロシージャは以下の通りである：
【００３９】
【表７】
0005155429.tif 000008
【００４０】
3.1  オラクル・テーブルMM_LOGにおける監査ログ
MM_LOGテーブルの構造
【００４１】
【表８】
0005155429.tif 000009
【００４２】
レコードは、各プロセスごとにMM_LOGに付加される。プロセスの名前はPROCESSカラムにある。キューブ固有プロセスの場合、キューブの名前はキューブCUBE_NAMEカラムにある。プロセスが順調に完了したら、RETURN_CODEカラムは0を含み、エラーがあれば、RETURN_CODEカラムは1を含む。
【００４３】
3.2  初期化
スクリプト使用法：mm00_initプロシージャは、ウィークリー・マーケット監視キューブ処理のための環境を初期化する。mm00.shシェル・スクリプトはmm00_initプロシージャを呼び出す。
入力：なし
出力：MM_LOGテーブルは切捨てられる。
MM_VARSテーブルは切捨てられる。
CUBE_DATA_TEXTテーブルは切捨てられる。
MM_LOGテーブル−成功完了かエラー状態かを示す行が挿入される。
【００４４】
3.3  変数設定
スクリプト使用法：mm01_set_varsプロシージャは、Rxマーケット監視ウィークリー・キューブ処理のための変数を設定する。mm01.shシェル・スクリプトはテキストとして設定される入力変数と一緒にmm01_set_varプロシージャを呼び出す。mm00_initプロシージャが既に実行されていなければならない。
入力：p_run_date    テキスト‘YYYYMMDD’として引き出し実行日
p_start_date        テキスト‘YYYYMMDD’として引き出し開始日
p_end_date          テキスト‘YYYYMMDD’として引き出し終了日
p_post_date         テキスト‘YYYYMMDD’として引き出し掲示日
p_acute_lookback    テキスト‘YYYYMMDD’としてアキュート・ルックバック日
p_chronic_lookback  テキスト‘YYYYMMDD’としてクロニック・ルックバック日
出力：MM_VARSテーブル−DATEデータタイプとしてこの週の値と一緒に行が挿入される
MM_VARS_HISTテーブル−DATEデータタイプとしてこの週の値と一緒に行が挿入される
MM_LOG−成功完了かエラー状態かを示す行が挿入される
【００４５】
3.4  ウィークリー・データ引き出し
スクリプト使用法：mm02_weekly_data_pullプロシージャは、ウィークリーRxマーケット監視キューブ処理のために1週間分のRxデータを引き出す。mm02.shシェル・スクリプトは、テーブルスペース変数入力設定と共にこのプロシージャを呼び出す。mm00_init及びmm01_set_varsプロシージャが、既に実行されていなければならない。
入力：p_tablespace        テキストとしてテーブルスペース名
MM_VARSテーブル
WH_ENVOY_YYMM、ここでYYMMはMM_VARSテーブルにおけるstart_dateからの2文字の年および月である。
WWW_MASTER_DOI
出力：前週のWEB_DATA_WEEK_PULLテーブルはWEB_DATA_WEEK_PULL_YYYYMMDDに名前変更される。ここで、YYYYMMDDはMM_VARSテーブルにおけるstart_dateの前日である。
新しいWEB_DATA_WEEK_PULLテーブルがp_tablespaceパラメータにおいて指名されるテーブルスペースにWEBスキーマで生成される。WEB_DATA_WEEK_PULLテーブルは、MM_VARSテーブルの開始日及び終了日からのRxデータを含んでいる。
MM_LOG−成功完了かエラー状態かを示すために行が挿入される。
【００４６】
3.5  memidの取得
スクリプト使用法：mm03_memidsプロシージャは、6週間分のmemid（メンバー識別番号）を累積する。mm03.shシェル・スクリプトは、このプロシージャを呼び出し、テーブルスペース・パラメータを入力する。mm00_init、mm01_set_vars及びmm02_weekly_data_pullプロシージャが既に実行されていなければならない。
入力：p_tablespace        テキストとしてテーブルスペース名
MM_VARSテーブル
ALL_MEN_TO_CONVERTテーブル
WEB_DATA_WEEK_PULL_V2テーブル
WEB_UMENS_WEEK_V2_MONDDテーブル。ここで、MONDDはテキストとしてのMM_VARSテーブルからのend_dateである。
WEB_UMENS_WEEK_V2_MONDD[1-5]テーブル。ここでMONDD[1-5]は前5週分のデータである。
RXMEMID_SEQテーブル
出力：WEB_UMENS_WEEK_V2_MONDDテーブルが生成される。ここで、MONDDはMM_VARSテーブルにおけるstart_dateマイナス1日である。
WEB_UMENS_WEEL_PULLが現行週及び前5週間のデータで生成される。
MM_LOG−成功完了かエラー状態かを示すために行が挿入される。
【００４７】
3.6  Mx診断取得
スクリプト使用法：mm04_mx_diagsプロシージャは、ウィークリー処理のためにMxテーブルから診断情報を取得する。mm04.shシェル・スクリプトは、テーブルスペース入力変数設定と共にこのプロシージャを実行する。mm00_init、mm01_set_vars、mm02_weekly_data_pull及びmm03_memidsプロシージャが既に実行されていなければならない。
入力：p_tablespace        テキストとしてテーブルスペース名
MM_VARSテーブル
WEB_UMENS_WEEK_PULL_V2テーブル
MASTER_PXテーブル
WEB_MXPTS_WEEK_PULL_V2テーブル
WH_ENVOY_MX_YYYYMM[1-3]、ここでYYYYMM[1-3]は現行月、前月及び前々月分のデータである。
WEB_RXMX_WEEK_PULL_V2テーブル
RXMEMID_SEQテーブル
出力：ACUTE RXMXテーブル−該当週からのレコードが付加される。
CHRONIC_RXMXテーブル−該当週からのレコードが付加される。
MM_LOGテーブル−成功完了かエラー状態かを示すために行が挿入される。
【００４８】
4.  TCキューブ・データ生成（ステップ304）
ステップ304（図3）のTCキューブ・データ生成プロセスについて図11を参照しながら説明する。
【００４９】
TCキューブ・データ生成プロセス304は、3つのオラクル記憶プロシージャを使って1つのキューブ・テーブルを生成し、キューブ・テーブルは、さらにCOGNOS読み取り可能な多次元フォーマットのキューブ構造を構築するためにデータ・トランスフォーマによって使用される。最後に記憶されたプロシージャは、各キューブの統計値を更新する。記憶済みプロシージャは以下の通りである：
mm05_step1
mm06_step2
mm07_step3
mm08_cube_metada
【００５０】
4.1  プロセス・ステップ1101（ステップ1）
スクリプト使用法：mm05_step1プロシージャは、各治療クラスごとに実行されなければならない。このプロシージャは、レコードをCMID_V2_CLASSテーブルに挿入する。ここで、CLASSは指定されるp_classである。mm00_init、mm01_set_vars、mm02_weekly_data_pull、mm03_memids及びmm04_mx_diagsプロシージャが既に実行されていなければならない。
入力：p_class         クラス名
p_tablespace    テキストとしてテーブルスペース名
p_lookback      ルックバックの日数
p_condition     “ACUTE（急性）”または“CHRONIC（慢性）”
MM_VARSテーブル
WEB_DATA_WEEK_PULL_V2テーブル
CUBE_V2_LISTテーブル
CMID_V2_CLASSテーブル。ここで、CLASSはp_classである。
出力：レコードがCMID_V2_CLASSテーブルに挿入される。ここで、CLASSはp_classである。
新しいCMID_V2_CLASS_TMPテーブルが生成される。ここで、CLASSはp_classである。
MM_LOGテーブル−成功完了かエラー状態を示すために行が挿入される。
【００５１】
4.2  プロセス・ステップ1102（ステップ2）
スクリプト使用法：mm06_step2プロシージャは各治療クラスごとに実行されなければならない。このプロシージャは、レコードをRX_RESULT_V2_CLASSテーブルに挿入する。ここで、CLASSは、このプロシージャが呼び出されるときに指定されるp_classである。mm00_init、mm01_set_vars、mm02_weekly_data_pull、mm03_memids、mm04_mx_diags及びmm05_step1プロシージャが既に実行されていなければならない。
入力：p_class         クラス名
p_tablespace    テキストとしてテーブルスペース名
p_lookback      ルックバックの日数
p_condition     “ACUTE（急性）”または“CHRONIC（慢性）”
MM_VARSテーブル
CMID_V2_CLASS_TMPテーブル。ここで、CLASSはp_classである。
RX_RESULT_TEMP_CLASSテーブル。ここで、CLASSはp_classである。
ZIP_ST_MSA_REG_DIVテーブル
WEB_DEA_TO_SPEC_U
出力：新しいレコードがRX_RESULT_V2_CLASS に挿入される。ここで、CLASSはp_classである。
MM_LOGテーブル−成功完了かエラー状態かを示すために行が挿入される。
【００５２】
4.3  プロセス・ステップ1103（ステップ3）
スクリプト使用法：mm07_step3プロシージャは、各治療クラスごとに実行されなければならない。このプロシージャは、新しいRXMX_CUBE_V2_CLASSテーブルを生成する。ここで、クラスは指定されるp_classである。mm00_init、mm01_set_vars、mm02_weekly_data_pull、mm03_memids、mm04_mx_diags、mm05_step1及びmm06_step2プロシージャが既に実行されていなければならない。
入力：p_class         クラス名
p_tablespace    テキストとしてテーブルスペース名
p_lookback      ルックバックの日数
p_condition     “ACUTE（急性）”または“CHRONIC（慢性）”
RXMX_CONDITION_V2テーブル。ここでCONDITIONはp_conditionである。
RX_RESULT_V2_CLASSテーブル。ここで、CLASSはp_classである。
ICD9_V2_CLASSテーブル。ここでCLASSは、p_classである。
RX_RESULT_V2_CLASS_Mテーブル。ここで、CLASSはp_classである。
出力：新しいRXMX_CUBE_V2_CLASS が生成される。ここで、CLASSはp_classである。
MM_LOGテーブル−成功完了かエラー状態を示すために行が挿入される。
【００５３】
4.4  キューブ・メタデータ生成
スクリプト使用法：mm08_cube_metadataプロシージャは、各治療クラスごとに実行されなければならない。このプロシージャは、各キューブのCUBE_DATAテーブルを更新する。mm00_init、mm01_set_vars、mm02_weekly_data_pull、mm03_memids、mm04_mx_diags、mm05_step1、mm06_step2及びmm07_step3プロシージャが既に実行されていなければならない。
入力：p_class        クラス名
MM_VARSテーブル
CUBE_DATAテーブル。ここでCLASSはp_classである。
出力：CUBE_DATA_TEXTテーブルが付加される。ここで、CLASSはp_classである。
MM_LOGテーブル−成功完了かエラー状態かを示すために行が挿入される。
【００５４】
5.  キューブ構成（ステップ305）
ステップ305（図3）のキューブ構成プロセスについて図9Aを参照しながら下に詳しく説明する。
【００５５】
このプロセスは、各治療クラスごとにキューブを生成するためにCプログラムを使用する。各キューブはSITE 3のサーバにFTP転送される。各キューブ用のメタデータは、テキスト・ファイルにスプールされて、SITE 3サーバにFTP転送される。同じテキスト・ファイルを連結して、eメールでSITE 2のウェブ・ディベロッパに送信することができる。
【００５６】
5.1  キューブ構成
スクリプト使用法：プログラムRSSERVERは、各治療クラスごとに反復され、スクリプトmmv2_’class name’.shによって呼び出される。データ・トランスフォーマは、最終的に各治療クラスごとのCUBEを構成するために、モデル・ストラクチャ及びOBES_RX_CUBEオラクル・テーブル（上記プロセスにおいて構成される）を使用する。このキューブは、その後、ウェブにおいて要請される情報を示すためにCOGNOSによって使用される。
入力            ：OBES_RXMX_CUBE
出力            ：OBESクラスごとのキューブ
周波数          ：要請に応じて
実行時間        ：〜8時間
【００５７】
5.2  SITE 3サーバへのキューブのFTP転送
スクリプト使用法：transfer_mm_cube.shスクリプトは、キューブの名前を変更し、コピーをディレクトリ/raid4011/cubes/transferに入れる。ここで、コピーは自動的にSITE 3サーバにFTP転送される。このスクリプトは各クラスごとに並行して実行される（クラスはキューブに該当する）。
【００５８】
5.3  キューブ承認
スクリプト使用法：approve_cubeスクリプトは、品質保証が実施された後各キューブごとに手動で実行される。このスクリプトは、各クラスごとに並行して実行される（クラスはキューブに該当する）。
【００５９】
5.4  メタデータ・テキスト・ファイルの生成／SITE 3サーバへのFTP転送
スクリプト使用法：プロセスgen_mm_file.sqlは、キューブ用のメタデータをテキスト・ファイルにスプールするためにgen_mm_file.shによって呼び出される。テキスト・ファイルはディレクトリに入れられて、ここで、自動的にSITE 3サーバにFTP転送される。このスクリプトは、各クラスごとに並行して実行される。キューブ・データを引き出すための全てのプロシージャがきちんと完了していなければならず、メタデータがオラクル・テーブルcube_dataおよびcube_data_textに存在しなければならない。
【００６０】
5.5  ウェブ・ディベロッパへのメタデータeメール送信
スクリプト使用法：email_meta.shスクリプトは、メタデータをSITE 2ウェブ・ディベロッパにeメール送信する。このスクリプトは各クラスごとに並行して実行される（クラスはキューブに該当する）。
【００６１】
6.  自動キューブ配備及びメタデータ更新プロセス
品質保証（QA）確認準備のできたデータ・キューブ（Quintiles Transnational Corp.のQUINTERNETTMシリーズなど）をプロダクションウェブサイト に配備するため、及び自動的にプロダクションウェブページの「メタデータ」を更新するために、自動プロセスがオンライン分析処理（OLAP）ホスト・マシンに存在する。これによって、プロダクションキューブ配備及びウェブページ更新を手動で介入することなくオフピーク時に行なうことができる。
【００６２】
QUINTERNETTMシリーズのデータ・キューブが生成されると、キューブは安全な接続を通じてホスト・マシンに送信される。次に、キューブは、自動的にウェブのQAロケーションに「サーブ・アップ」され、このロケーションには認可された者しかアクセスできない。
【００６３】
各キューブ承認ごとに「メタデータ」ファイルがSITE 2サーバから安全な接続を通じてホスト・マシンの特定のロケーション（ファイル・システム内のディレクトリ）に伝送される。この安全な伝送は、データ・キューブがQA確認を送った後行なうことができる。
【００６４】
メタデータ・ファイルは、特定のキューブに関する統計情報を含んでいる（例えば、キューブがデータを含んでいる期日、レコードの数、患者の数など）。毎夜数回、メタデータ・ファイル及び該当するデータ・キューブ・ファイルの存在をチェックする自動プロセスを開始することができる。特定のキューブに整合するファイルが存在する場合、このプロセスは、ウェブページを通じてアクセスするために自動的にこのキューブをプロダクションに「サーブ・アップ」する。さらに、このキューブ用のメタデータを含んでいるHTMLページが、メタデータ・ファイルに含まれるメタデータで更新される。
【００６５】
例えばSITE 3のサーバは、各QUINTERNETTMシリーズのキューブのためにHTMLテンプレート・ファイルを作成し維持することができる。このファイルは、各キューブのウェブページを生成するために使用されるベースHTMLを含んでいる。キューブのウェブページに存在する実際のメタデータ値の代わりに、HTMLテンプレート・ファイルは、プレースホルダー・タグを含むことができる。このプレースホルダー・タグは、SITE 2によって提供されるメタデータ・ファイルの中のデータ値と置き換えられる。
【００６６】
SITE 2は、FTPを通じてテンプレート・ファイル及びメタデータ・ファイルをホストに転送する。メタデータ・ファイルは、キューブが承認されるごとにホストに転送される。テンプレート・ファイルは、各QUINTERNETTMシリーズのキューブごとに保存され、各キューブのテンプレート・ファイルの現バージョンが常にホスト上で処理のために利用可能であるように、必要に応じてSITE 2によって更新される。
【００６７】
あるキューブが更新され、品質が検査され、SITE 2のオペレータによって承認された後、SITE 2は、FTPを通じてこのキューブ用のメタデータ・ファイルをホストに転送する。メタデータ・ファイルは各キューブ用のHTMLテンプレート・ファイルにあるのと同じタグを含んでいる。これらのタグの各々は、HTMLテンプレート・ファイルの中のプレースホルダー・タグの代用となる値と結合される。
【００６８】
イベント・ドリブン式ファイル処理スクリプトは、Unix（登録商標）スケデューリング・システムであるcronを通じてホストで定期的に実行される。このファイル処理スクリプトが指定されるフラグ・ファイルの存在を検出すると、enable_cube.kshと呼ばれるスクリプトが実行される。enabele_cube.kshスクリプトは、パール・スクリプトreplaceHtmlMetaTags.plを呼び出し、これに処理対象のキューブの名前及び関連メタデータ・ファイルの名前を送る。enabele_cube.kshスクリプトは、また、更新されたキューブが配備される日付を表すタグ/値の対でメタデータ・ファイルを更新する。
【００６９】
replaceHtmlMetaTags.plスクリプトの目的は、QUINTERNETTMシリーズ製品のためにHTMLページを自動的に生成することである。replaceHtmlMetaTags.plスクリプトは、テンプレートの中のプレースホルダー・タグの代わりにメタデータ・ファイルの中の値を代入し、その結果の出力をHTMLファイルに保存する。図1Cを参照すると、enable_cube.kshスクリプトは、次に、更新済みHTMLファイルをSITE 3のウェブサーバ181にプロモートするので、このファイルは、例えばインターネット183を通じて、クライアント・コンピュータで動作するウェブ・ブラウザ182のユーザに利用可能となる。
【００７０】
本発明は、多くの方法で定義される処理スケジュールで実現できる。例えば、スケジュールは、インプリメンテーションのニーズに応じて週間または月間とすることができる。時には、特殊な要求が必要とされる場合があり、特別にデータを処理しキューブを生成する能力が存在する。
【００７１】
以上、本発明の望ましい実施態様について論じたが、特許請求の範囲に示される発明の精神及び範囲から逸脱することなくシステムの要素及び方法のステップの形式及び配列にある程度の変更を加えることができると、理解されるべきである。
本願発明に関連する発明の実施態様は以下のとおりである。
実施態様１．匿名化された健康管理データを分析するためのシステムであり、(a)各々少なくとも1つのレコードを含む複数の健康管理データベースであり、各レコードが、1人の患者と対応付けられる匿名化されながらも一意の患者識別子を含み、それにより、前記匿名化された患者識別子が該複数の健康管理データベース全体を通じて特定の患者について共通である、複数の健康管理データベースと、(b)前記複数の健康管理データベースと結合されるプロセッサであり、該プロセッサが、(i)前記複数の健康管理データベースからレコードを受け取るステップと、(ii)選択された個人レベルの基準に基づいて、前記複数の健康管理データベースから受け取ったレコードを問い合わせるステップと、(iii)前記問い合わせステップの結果に基づいて少なくとも1つのレポートを生成するステップと、を実行するプロセッサとを備えるシステム。
実施態様２．前記システムにおいて、前記匿名化された健康管理データが医薬請求データを含む実施態様1に記載のシステム。
実施態様３．前記システムにおいて、前記プロセッサによって実施される前記生成ステップが、特定の分析目標を満たす特定のビューで表示するために結果を処理するステップを含む実施態様1に記載のシステム。
実施態様４．前記システムにおいて、前記プロセッサによって実施される前記生成ステップが、表形式でレポートを表示するステップを含む実施態様1に記載のシステム。
実施態様５．複数の健康管理データベース内の匿名化された健康管理データを分析するための方法であり、前記複数の健康管理データベースが各々、少なくとも1つのレコードを含み、各レコードが、1人の患者と対応付けられる匿名化されながらも一意の患者識別子を含み、それにより、前記匿名化された患者識別子が前記複数の健康管理データベース全体を通じて特定の患者について共通であり、前記方法が、(a)前記複数の健康管理データベースからレコードを受け取るステップと、(b)選択された個人レベルの基準に基づいて、前記複数の健康管理データベースから受け取ったレコードを問い合わせるステップと、(c)前記問い合わせステップの結果に基づいて少なくとも1つのレポートを生成するステップと、を含む方法。
実施態様６．前記方法において、前記匿名化された健康管理データが医薬請求データを含む実施態様5に記載の方法。
実施態様７．前記方法において、前記生成ステップが、特定の分析目標を満たす特定のビューで表示するために結果を処理するステップを含む実施態様5に記載の方法。
実施態様８．前記方法において、前記生成ステップが、表形式でレポートを表示するステップを含む、実施態様5に記載の方法。
実施態様９．健康管理データベースにおいて識別される個人に対応付けられる一意のエイリアスを生成するためのシステムであり、(a)少なくとも1つのレコードを記憶するための第一のデータ記憶装置であり、各レコードが、ひとまとめにされると一意にある個人を識別する複数の識別フィールド、及び前記個人に対応付けられる健康管理データに該当する少なくとも1つの健康管理フィールドを含む、第一のデータ記憶装置と、(b)第二のデータ記憶装置と、(c)(i)前記第一のデータ記憶装置の1つのレコードを選択するステップと、(ii)前記選択されたレコード内の前記複数の識別フィールドのサブセットを選択するステップと、(iii)前記選択された識別フィールドのサブセットを連結するステップと、(iv)前記連結された識別フィールド並びに前記第一のデータ記憶装置の選択されたレコードからの前記少なくとも1つの健康管理フィールドを、前記第二のデータ記憶装置のレコードに記憶するステップと、を実行するためのプロセッサと、を備えるシステム。
実施態様１０．前記システムにおいて、前記第一のデータ記憶装置に記憶される前記健康管理データが医薬請求データに該当する実施態様9に記載のシステム。
実施態様１１．前記システムにおいて、前記第一のデータ記憶装置及び前記第二のデータ記憶装置が両方とも同じデータベースに配置される実施態様9に記載のシステム。
実施態様１２．前記システムにおいて、前記第一のデータ記憶装置及び前記第二の記憶装置が異なるデータベースに配置される実施態様9に記載のシステム。
実施態様１３．前記システムにおいて、前記選択されたサブセットが、姓、生年月日及び性別を含む実施態様9に記載のシステム。
実施態様１４．前記システムにおいて、前記プロセッサが、さらに(iv)前記第二のデータ記憶装置の各レコードの前記連結された識別フィールド及び前記少なくとも1つの健康管理フィールドに基づいて、個人レベル・リンク方法を使って個人の長期的履歴レコードを分析するステップ、を実行する、実施態様9に記載のシステム。
実施態様１５．健康管理データベースにおいて識別される個人に対応付けられる一意のエイリアスを生成するためのシステムであり、前記データベースが、少なくとも1つのレコードを記憶するための第一のデータ記憶装置であり、各レコードがひとまとめにされると一意にある個人を識別する複数の識別フィールド及び前記個人に対応付けられる健康管理データに該当する少なくとも1つの健康管理フィールドを含む、第一のデータ記憶装置、及び第二のデータ記憶装置を含み、該システムが、(a)前記複数の識別フィールドのサブセットを選択するための手段と、(b)前記選択された識別フィールドのサブセットを連結するための手段と、(c)前記連結された識別フィールド並びに前記第一のデータ記憶装置の前記選択されたレコードからの前記少なくとも1つの健康管理フィールドを、前記第二のデータ記憶装置のレコードに記憶するための手段と、を備えるシステム。
実施態様１６．健康管理データベースにおいて識別される個人に対応付けられる一意のエイリアスを生成するための方法であり、該方法において、前記健康管理データベースは、少なくとも1つのレコードを記憶し、各レコードが、ひとまとめにされると一意にある個人を識別する複数の識別フィールド及び前記個人に対応付けられる健康管理データに該当する少なくとも1つの健康管理フィールドを含み、該方法が、(a)前記健康管理データベース内の1つのレコードを選択するステップと、(b)前記選択されたレコード内の前記複数の識別フィールドのサブセットを選択するステップと、(c)前記選択された識別フィールドのサブセットを連結するステップと、(d)前記連結された識別フィールド並びに前記第一のデータ記憶装置の前記選択されたレコードからの前記少なくとも1つの健康管理フィールドを、第二のデータベースのレコードに記憶するステップと、を含む方法。
実施態様１７．さらに、(e)前記第二のデータベースの各レコードの前記連結された識別フィールド及び前記少なくとも1つの健康管理フィールドに基づいて、個人レベル・リンク方法を使って、個人の長期的履歴レコードを分析するステップ、を含む実施態様16に記載の方法。
【図１Ａ】
0005155429.tif 000010
【図１Ｂ】
0005155429.tif 000011
【図１Ｃ】
0005155429.tif 000012
【図１Ｄ】
0005155429.tif 000013
【図１Ｅ】
0005155429.tif 000014
【図２Ａ】
0005155429.tif 000015
【図２Ｂ】
0005155429.tif 000016
【図２Ｃ】
0005155429.tif 000017
【図３Ａ】
0005155429.tif 000018
【図３Ｂ】
0005155429.tif 000019
【図４】
0005155429.tif 000020
【図５】
0005155429.tif 000021
【図６】
0005155429.tif 000022
【図７】
0005155429.tif 000023
【図８】
0005155429.tif 000024
【図９】
0005155429.tif 000025
【図９Ａ】
0005155429.tif 000026
【図１０】
0005155429.tif 000027
【図１１Ａ】
0005155429.tif 000028
【図１１Ｂ】
0005155429.tif 000029