(57)【要約】非揮発性のコンポーネント、及び／又は、コークス・プリカーソルを含む軽炭化水素供給原料をクラックする方法であって、重炭化水素供給原料が、炭化水素供給原料混合を形成するために、汚染した軽炭化水素供給原料に加えられる。汚染した軽炭化水素供給原料は、後に、フラッシュ／分離ベッセルのフラッシュ化、蒸気フェーズの分離及びクラック化、及びクラックした物を復元化により、蒸気フェーズ及び液体フェーズに分離される。重炭化水素供給原料は、分離ベッセルの動作する温度範囲内で、より高い温度でフラッシュ／分離ベッセルの動作を許容する。
2008503798.tif 000002
【特許請求の範囲】
【請求項１】
個々の患者のヘルスケア・トランザクションデータ記録から長期リンク化データベースをアセンブリする方法であって、
(a) データ供給者サイトで、患者識別属性及び非識別属性を有する取得したデータ記録の処理を仲介する実装パートナー（IP）を配置することにより、前記データ記録を長期のデータベース装置（LDF）に安全に送信するように、前記データ記録内の少なくとも前記患者識別属性を暗号化するステップと、
(b) 前記LDFで、前記暗号化したデータ記録を受信するステップと、
(c) 前記受信したデータ記録の仲介する前記IPを配置することにより、前記データ記録内の前記暗号化した患者識別属性の値に基づいて、LDF識別子（ID）を前記データ記録に割り当て、前記暗号化したデータ記録を、ID毎に長期にリンクすることを可能とするステップとを含み、
前記ステップ(a)及び(c) において、前記データ記録の処理が、前記IPに対してのみアクセス可能な安全な処理環境において実行される方法。
【請求項２】
前記ステップ(a)における前記取得したデータ記録の処理が、
(d) 前記LDFに対して特定の第1の暗号鍵を用いて、前記データ記録における患者識別の属性を暗号化するステップと、
(e) 前記データ供給者に対して特定の第2の暗号鍵で、前記患者識別の属性を更に暗号化するステップとを含む請求項1に記載の方法。
【請求項３】
前記ステップ(c)における前記受信したデータ記録の処理が、
(f) 前記患者識別の属性が、前記LDFに対して特定の前記第1の暗号鍵による前記ステップ(d)の暗号化のみを保持するように、前記受信したデータ記録を部分的に解読するステップを含む請求項2に記載の方法。
【請求項４】
前記ステップ(f)の後に、第3の暗号鍵を用いて前記属性を付加的に暗号化するステップ(g)を更に含む請求項３に記載の方法。
【請求項５】
前記暗号化したデータ記録に対してLDF識別子（ID）を割り当てる属性マッチングアルゴリズムを用いるステップ(h)を更に含む請求項３に記載の方法。
【請求項６】
前記暗号化したデータ記録をID毎にリンクし、前記長期にリンクしたデータベースを形成するステップ(i)を更に含む請求項5に記載の方法。
【請求項７】
前記IPが、ソフトウェア、ハードウェア、中立のエンティティ、及び、それらいずれかの組み合わせの１つを含む請求項1に記載の方法。
【請求項８】
前記取得したデータ記録を前処理し、前記データ記録のデータ・フィールドを標準形式にするステップを更に含む請求項1に記載の方法。
【請求項９】
前記ステップ(a)及び(c)が、前記IPによる暗号化／解読の鍵のプロビジョンを含む請求項1に記載の方法。
【請求項１０】
前記ステップ(a)及び(c)における前記IPによる仲介が、前記データ記録の患者識別の属性情報に対する不正アクセスを制限する安全な環境処理環境のプロビジョンを含む請求項1に記載の方法。
【請求項１１】
長期のデータベース装置（LDF）によって複数のデータ供給者から受信した個々の患者のヘルスケア・トランザクションデータ記録から、長期リンク化データベースをアセンブリするシステムであって、
データ供給者サイトで患者識別属性及び非識別属性を有するデータ記録の処理を仲介することにより、前記データ記録を前記LDFに対して安全に送信することを可能とするように、前記データ記録における少なくとも前記患者識別属性を暗号化し、前記LDFで前記受信したデータ記録の処理を更に仲介することにより、前記データ記録内の前記暗号化した患者識別属性の値に基づいて、識別子（IP）をデータ記録に割り当て、前記LDFで、前記暗号化したデータ記録をID毎に長期にリンクすることを可能とする実装パートナー（IP）と、
前記データ供給者サイト、及び、前記IPに対してのみアクセス可能とする前記LDFを含む安全なデータ処理環境とを備えるシステム。
【請求項１２】
前記データ記録の属性を標準形式にするように、前記IPが、データ供給者サイトでの前記データ記録の処理を仲介する請求項11のシステム。
【請求項１３】
(a) 前記データ記録における前記患者識別の情報が、前記LDFに対して特定の第1の暗号鍵を用いて暗号化され、
(b) 前記データ記録における前記患者識別の情報が、前記データ供給者に対して特定の第2の暗号鍵で更に暗号化されるように、
前記IPが、データ供給者サイトでの前記データ記録の処理を仲介する請求項11のシステム。
【請求項１４】
前記受信したデータ記録が部分的に解読されることにより、前記患者識別の属性が前記LDFに対して特定の前記第1の暗号鍵による暗号化のみ保持するように、前記IPが、前記LDFで前記受信したデータ記録の処理を仲介する請求項13のシステム。
【請求項１５】
前記受信したデータ記録が第3の暗号鍵を用いて更に暗号化されるように、前記IPが、前記LDFで前記受信したデータ記録の処理を仲介する請求項13のシステム。
【請求項１６】
前記暗号化した属性の値に基づいて、前記暗号化したデータ記録にIDを割り当てるように構成される属性マッチングアルゴリズムを備える請求項11のシステム。
【請求項１７】
前記IPが、ソフトウェア、ハードウェア、中立のエンティティ、及び、それらいずれかの組み合わせの１つを含む請求項11に記載のシステム。
【請求項１８】
前記IPが、暗号化／解読の鍵を与える請求項11に記載のシステム。
【請求項１９】
ID及び対応する属性のクロスデータベースを更に備える請求項11に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願）
この出願は、2004年5月5日に出願された米国特許仮出願第60/568,455号明細書、2004年5月17日の出願された米国特許仮出願第60/572,161号明細書、2004年5月17日の出願された米国特許仮出願第60/571,962号明細書、2004年5月17日に出願された米国特許仮出願第60/572,064号明細書、及び、2004年5月17日に出願された米国特許仮出願第60/572,264号明細書の利益を主張するものであり、これら全ての仮出願の内容は、本出願の明細書の内容に取り込まれる。
【０００２】
本発明は、個々において、個人の健康情報又はデータについての管理に関する。特に、本発明は、個人のプライバシを保持する方法に係る、長期のデータベースにおいて、そのようなデータのアセンブリと使用に関する。
【背景技術】
【０００３】
患者の健康記録の電子データベース化は、商業利用及び非商業的利用の双方に役立つものである。例えば、長期（寿命期間）の患者記録データベースは、疫学的に、又は、時間傾向、因果関係、又は、ある母集団における健康事象の発生率の分析としての母集団ベースの研究として用いられる。長期のデータベースでアセンブリされた患者記録は、複数のソースから、様々な形式で収集させられるようである。患者健康記録の明白なソースは、現代においては健康保険業界であり、その業界は、医療サービスプロバイダに対して保険金を与えるために、電子通信型の患者のトランザクション記録を広く頼りにしている。医療サービスプロバイダ（例えば、薬局、病院または診療所）、又は、医療サービスプロバイダのエージェント（例えば、データクリアリングハウス、プロセッサ又はベンダー）は、個別に特定された患者トランザクション記録を、補償金のために保険業界に供給する。患者トランザクション記録は、個人情報データのフィールド、即ち属性に加えて、例えば、診断、処方箋、治療内容又は治療結果などの他の情報を含むことができる。複数のソースから取得したそのような情報は、長期の研究に対して貴重となる場合がある。しかしながら、個人のプライバシを保護するために、長期のデータベース装置に統合される患者記録は、“匿名型”、即ち“非識別型”とされることが重要である。
【０００４】
データ供給者、即ちデータ・ソースは、転送前に患者プライバシを保護するために、患者トランザクション記録の個人情報データのフィールド、即ち属性（例えば、名前、社会保険番号、住所、ジップコードなど）を除去又は暗号化できる。患者プライバシを保護するために、ある個人情報データのフィールドの暗号化又は標準化は、現在、法令と政令によって規制されている。個人の民事的権利に対する関心事は、電子取引における、患者記録の収集についての政府規制と個人的な健康データの使用に向けられている。例えば、「医療保険の相互運用性と説明責任に関する法律（1996年）（HIPAA法）」の下で発行された規制は、個人的な健康情報のセキュリティ及び秘匿性をセーフガードするように、緻密な規則を含む。HIPAA規制は、保健保険プラン、ヘルスケア・クリアリングハウス、及び、ある財政用及び管理用のトランザクション（例えば、登録、支払い、及び適正検査）を電子的に行うヘルスケア・プロバイダなどの実体をカバーしている。(例えば、http://www.hhs.gov/ocrhxipaa 参照)。2004年7月15日に出願された、共通に発明され、共に譲渡された、“Data Privacy management Systems and Methods”と題される特許出願第10/892,021号明細書（代理人整理No.AP35879）は、本出願の明細書の内容に取り込まれるものであるが、政令のHIPAA規制又は他のプライバシ規則の組に従って標準化された形式における、個人的な健康情報を収集及び使用するシステム及び方法について、記載されている。
【０００５】
患者のプライバシの侵害についてのリスクを更に最小化するために、長期のデータベースを構成するように用いられる患者記録から、全ての患者識別情報を分離又は除去することが望ましいと考えられる。しかしながら、患者識別情報をデータ記録から分離し、患者識別情報を完全に匿名にすることは、格納されたデータ記録が、患者毎にリンク可能でなければならない長期のデータベースの構成と互換性がなくなる場合がある。
【０００６】
ここでは、長期のデータベースにおける種々のデータ・ソースからの患者記録を“匿名型”、即ち“非識別型”で統合することに対して考慮をしている。特に、データ収集、及び、長期データベースをアセンブリする処理エンタープライズにおいて、患者プライバシを保護するシステム及び方法に注意を向けている。尚、エンタープライズは、幾つかのデータ供給者サイト及び長期のデータベース装置に及ぶものとできる。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
ヘルスケアデータ記録が、長期にリンクしたデータベースにおいてアセンブリされる、個々のプライバシを管理するシステム及び方法を提供する。本システム及び方法を、データ収集及び処理エンタープライズにおいて実現することができる。本システム及び方法は、地理的に多様なものとでき、幾つかのデータ供給者と共通の長期のデータベースアセンブリ装置を含むことができる。
【課題を解決するための手段】
【０００８】
本システム及び方法は、データ供給者サイトで、及び、において、マルチソース型のデータ記録がデータベースでアセンブリされる共通の長期のデータベース装置で、データ処理記録を伝える中立の第三者（即ち、実装パートナー）を含む。未認証のパーティが、処理されているデータ記録における機密の個人識別の情報又は情報にアクセスをすることができないように、本システム及び方法は、構成される。データ記録が、長期のデータベース装置に送られる前に、2つの連続するレベルの暗号化で、二重暗号化されるように、機密のデータ属性が、データ記録は、まず、データ供給者サイトで処理される。データ記録を個々のレベルで直意のデータベースへと統合する作成において、あるレベルの暗号化を除去するように、これら二重暗号化したデータ記録は、長期のデータベース装置で処理される。データ供給者サイト及び長期のデータベース装置でのデータの暗号化及び解読は、安全な処理環境において、中立の第三者によって制御され、それは、機密の患者識別情報の故意又は不注意のリリースのリスクを低減又は削減する。
【０００９】
本発明の更なる特徴、本質、及び様々な利点は、図面、及び以下の詳細な説明から明らかになる。
【発明を実施するための最良の形態】
【００１０】
患者ヘルスケア記録の、長期にリンクされるデータベースのアセンブリにおいて、患者プライバシを管理し、保証するシステム及び方法が低級される。本システム及び方法は、データ収集及び処理エンタープライズにおいて実現でき、地理的に多様なものとでき、幾つかのデータ供給者と他のパーティを含むことができる。例えば、本システム及び方法は、2005年5月5日に出願された共有に係る特許出願第_______号明細書（代理人整理番号AP36247）（その出願の内容は、本明細書の内容に取り込まれる）に開示される長期のデータベース・アセンブリシステムと関連して、実現することができる。
【００１１】
取り込まれたその特許出願は、患者プライバシの侵害の如何なるリスクも生成することなく、複数のソースから取得した患者データ記録が、長期のデータベースへと個々の患者毎に統合されることを可能とする解決策を開示する。その解決策は、データ記録における機密の患者識別の情報を暗号化するように、複数の暗号鍵を用いて、2ステップの暗号化処理を用いる。（図1参照）。暗号化処理は、データ供給者サイト（例えば、サイト116、図1）で実行される暗号化ステップと、また、長期のデータベース装置（“LDF”）（例えば、サイト130、図1）で実行される暗号化／解読ステップとを含む。第1のステップで、各DSは、患者記録における選択したデータ・フィールド（例えば、患者識別の属性、及び／又は、他の標準化した属性データ・フィールド）を暗号化し、患者記録を第1の“匿名型”形式に変換する。引き続き図1を参照して、各DSは、2つの鍵（即ち、DS特定鍵K2、特定のLDFで関連付けられた共通の長期鍵K2）を用いて、選択したデータ記録を二重暗号化する。二重暗号化したデータ記録は、LDFサイトに送信される。次に、データ記録は、第2の匿名型形式へと処理され、第2の匿名型形式は、元の暗号化していない患者識別情報を回復することなく、データ記録が個々の患者毎にリンクされることを可能とするように構成される。このため、DSから受信した患者記録における二重暗号化したデータ・フィールドは、特定のDS鍵K2’を用いて部分的に解読される（二重暗号化したデータ・フィールドが、まだ共通の長期鍵暗号化を保持しているように）。第3の鍵（例えば、トークン・ベースの鍵、K3）は、更にデータ記録を暗号化するように用いることができ、第3の鍵で暗号化したデータ記録は、長期にリンクされるデータベースにおける使用のために、新たな単一の（共通の長期鍵）暗号化したデータ・フィールド又は属性を含む。長期のデータベースに対して内部的である、長期の識別子（ID）又はダミーラベルは、データ記録をタグ付けするように用いることができる。これにより、タグ付けされたデータ記録は、長期のデータベースにおいて、個々のID毎にマッチングされ、リンクされる。
【００１２】
本発明の一実施例において、単一のパーティ（即ち、データ供給者又はLDF）が全データ処理又はフローに対する完全なアクセスを有しないような、2ステップの暗号化処理において、プライバシ管理手順及びモデルは、ビジネスメカニズムを含む。例えば、LDFの人員又は利用者に対して患者識別情報の故意又は不注意のリリースの如何なるリスクも、これにより最小化される。
【００１３】
ビジネスメカニズムは、ハードウェア、ソフトウェア、及び／又は、第三者に関わることができる。ビジネスメカニズムは、安全な環境において、2ステップの暗号化処理の部分を実行するように呼び出される。ビジネスメカニズムは、データ供給者サイト及び／又はLDFに配置することができる、1つ以上のソフトウェアアプリケーションを含むことができる。ビジネスメカニズムは、データ供給者サイト及び／又はLDFで、ソフトウェア・コンフィグレーションのみ含むことができ、或いは、ソフトウェア及びハードウェアの双方を含むことができる。一実現例において、数十又は数百のデータ供給者サイト及びLDFを、ビジネスメカニズムでカバーできる。
【００１４】
ビジネスメカニズムは、複数のデータ供給者サイト及びLDFにわたって共通データ・暗号化アプリケーションの配置及びサポートに関わる。配置した共通データ・暗号化アプリケーションは、幾つかの暗号化及び／又は解読の鍵を、生成し、使用し、及び、安全にするアプリケーションを含むことができる。ビジネスメカニズムは、鍵生成機能、供給機能、管理機能、及びセキュリティ機能を提供又は監督するように構成される。
【００１５】
本発明の原理を用いて作成又は維持される長期のデータベースは、例えば製薬及びヘルスケア業界に対して、情報の解決策を提供するように利用されることができる。長期のデータベースは、数千のソースから収集される数十億の製薬の記録を、ワールドワイドにクライアントの戦略的洞察へと変えることができる。長期のデータベースの作成において利用されるビジネスメカニズムは、全ての収集したヘルスケア情報のプライバシ及びセキュリティを保護するように構成される。
【００１６】
長期のデータベースの一例は、米国ベースの処方箋のデータ供給者から提供されたデータを含むことができる。長期のデータベースから収集された市場状況及び分析は、研究開発の初期段階から、製品化の着手、製品化の成熟、及び特許権満了の段階までに及ぶ、製薬のライフサイクルの全てのステージで、カスタマー（例えば、製薬の研究開発機構又は製造者）に、クリティカルな技術的及びビジネス的事実を提供できる。例えば、市場状況及び分析は、対象とされる予測及び傾向の分析、カスタマイズされた製品の紹介情報、価格付け及び宣伝のパラメータ及びガイドライン、競合比較、市場シェアデータ、販売力の見通し及び生産性の評価、及び、製品製造者、地理学及びヘルスケアのセクタで、並びに、目録及び配布チャンネルでセグメント化された市場監査を含むことができる。
【００１７】
一実施例において、ビジネスメカニズムは、安全な環境で、2ステップの暗号化処理の部分を実行する、中間のエンティティ（例えば、第三者実装パーティ（“IP”）に関わる。IPは、例えば、データ供給者及びLDFとの発展関係に熟達した、好適な第三者パーティとできる。IPは、アプリケーションをサイト上で実現するエキスパートを有することができ、既存のクライアントから事例を提供可能とできる。事例は、大多数の標準的でない環境にわたる実現を含むことができる。IPは、地理的に様々なロケーションで（例えば、合衆国に跨って）アプリケーション・サポートを提供する能力を有することができ、そのサポートを提供するのに好適な組織的構造を有することができる。IPは、HIPAA規制、及び、個人の健康情報の収集及び処理に関する他の規格についての有効な理解又は指令を有することを要求できる。
【００１８】
IPの機能は、前述の取り込まれた特許出願第_______号明細書において開示される。長期のデータベースを構成するシステム及び方法を参照して理解することができる。（図1参照）。その取り込まれた特許出願による長期のデータベースを構成する処理は、3つの連続的なコンポーネント又はステージ110a、110b、及び110cを含むことができる。第1のステージ110aにおいて、クリティカル・データ暗号化処理は、データ供給者サイトで行われる。第2のステージ（110b）及び第3のステージ（110c）の処理は、複数のデータ供給者によって、暗号化したデータ記録が供給される、共通のLDFサイト130で行うことができる。第2のステージ110b では、ベンダー特定の暗号化データは、データ供給者にわたって長期にリンクされることができるLDFの暗号化データへと処理される。最後のステージ110cで、LDFの暗号化データは、様々な確率論的及び決定論的なマッチングアルゴリズムを用いて処理され、マッチングアルゴリズムは、固有のタグを暗号化したデータ記録に割り当てる。割り当てられたタグは、擬似又は架空の患者識別子（“ID”）として観ることができ、明白な患者識別情報を含むだけでなく、長期のデータベースを作成する統計的に有効な態様で、LDFの暗号化したデータを、長期にリンクするように効果的に用いることができる。マッチングアルゴリズム例は、2005年5月5日に出願された、共に係属している特許出願第_______号明細書（代理人整理番号AP36251）に開示されており、その出願の内容は、全体において本明細書の内容に取り込まれる。
【００１９】
マッチングアルゴリズムは、データ記録内の個人的に識別可能な選択組のデータ属性の暗号化した値に基づいて、特定のタグをデータ記録に割り当てることができる。長期のデータベースを構成する処理は、データ供給者によってLDFに送信されたデータ記録において、少なくとも選択組の属性が、取得され、暗号化されなければならないということを要求する。本発明によれば、IPは、選択組のデータ属性を含むデータ記録について、取得、暗号化及び伝送のための規定及び実現処理において、データ供給者を助力するように利用できる。第1のデータ供給者処理は、データ供給者のデータベース／ファイルのデータから必要な情報の識別及び取得のために用いられることができる。一旦、属性が取得されると、それら属性を、“C”又は“JAVA（登録商標）”で符号化できる暗号化アプリケーションによって処理できる。暗号化アプリケーションは、属性を標準化でき、更に、それら属性を、普遍的な長期の暗号鍵及びベンダー特定の暗号鍵を用いる二重暗号化処理を用いて暗号化できる。次に暗号化した属性の出力値を、データ供給者から既存のデータフィードの部分として又は個々のデータ伝送として安全な態様で、LDFに送信できる。データをマージするための、及び／又は、暗号化したデータファイルを送るための、好適なアプリケーション／環境を、規定することができる。データ供給者コンポーネントの実現においてデータ供給者を助力するように、及び、データ供給者に対して継続中の生産サポートを提供するように、IPを利用できる。
【００２０】
データ記録がLDFで受信された後、暗号化したデータ属性を安全な暗号化環境によって処理して、LDFの暗号化した属性を生成することができる。これら“新たな”LDFの暗号化した属性は、各データ・ソースにわたってリンク可能なように構成させることができる。暗号鍵及びソフトウェアを含む安全な暗号化環境は、IPによって管理され、監督されるIPは、LDFがこの安全な暗号化環境にアクセスを有しないことを確実にする。マッチングアプリケーションでの処理の最終ステージで、このステージから生じる暗号化した属性を処理することができ、マッチングアプリケーションは、長期のデータベースに取り込むためのデータ記録をタグ付けするように、長期の患者識別子（“ID”）を割り当てる。
【００２１】
IPは、利用される暗号化アプリケーションの所有権を有することができる。IPは、データ供給者及びLDF環境の双方において、これら及び他のアプリケーションを配置及び管理できる。暗号化アプリケーション及び処理が、インストールされ、検査される際に、及び、データ供給者及び／又はIPが、暗号化したデータ属性をLDFに“押し”戻すことを始める際に、代表的なデータ供給者サイトの配置は、スタートアップ期間を含むことができる。IPは、例えば、データ供給者の技術的プラットフォーム又は環境における変化から生じうる、データ供給者対データ供給者の処理変化を低減するようにサポートを提供できる。IPは、許容可能な標準化までデータ供給者の処理をもってくるように、スタートアップ中に、このサポートを提供できる。
【００２２】
データ供給者からLDFに、標準化したデータ記録をフィードする処理が、確立された（例えば、スタートアップ期間後）後に、IPは、メンテナンス、アプリケーションの更新、ヘルプ・デスク・サポート／問題解決、及び、潜在処理監査サポートを提供し続けることができる。
【００２３】
また、IPは、LDF又は中間サイトで、暗号化アプリケーションの部分をサポート配置及び管理できる。例えば、IPは、暗号化アプリケーションのインストール、暗号化アプリケーションに対する暗号化データの配送の調整、及び、LDF環境における暗号化アプリケーションの安全の保障を可能とする。IPは、初期のインストールの後に、メンテナンス、アプリケーションの更新、ヘルプ・デスク・サポート／問題解決、及び、潜在処理監査サポートを提供し続けることができる。
【００２４】
IPによって実行できる機能例は、以下を含む。
・データ供給者サイトで、暗号化アプリケーションのインストール及び検査。
・暗号化環境においてデータが保存されているところから、データを取得することについて助力、及び、そのデータを、実現される暗号化アプリケーションに提示。
・LDFへの暗号化したデータ結果の配送を確実にするためのデータ供給者との働き。
・インストールされ、完全に機能する暗号化アプリケーションの“LDFサイト”の取得。
・LDF環境における暗号化アプリケーション及びデータ記録の安全の確保。
【００２５】
前述の説明は、本発明の原理を単に示したものである。前述した実施例に対して様々な変形及び代替が実現できることは、当業者に明らかである。従って、前述の説明で明らかに記載されていない場合でも、本発明の趣旨及び範囲内で、当業者が本発明の原理を用いて、実施するための多数の技術を工夫できることは明らかである。
【図面の簡単な説明】
【００２６】
【図１】米国特許出願第________号明細書から再現される、マルチ・ソース型の患者データ記録から長期のデータベースをアセンブリするシステム例のブロック図であり、同図のシステムにおいて、上述の暗号化アプリケーションは、本発明の原理に従って実現できる。
【図１】
2008503798.tif 000003
【国際調査報告】
2008503798.tif 000004
2008503798.tif 000005