JP2008090855A

JP2008090855A - 健康管理データ通信システム

Info

Publication number: JP2008090855A
Application number: JP2007289554A
Authority: JP
Inventors: Ralph A Korpman; コープマン，ラルフ，エー．; John C Peterson; ピーターソン，ジョン，シー．; Cindy A Post; ポスト，シンディ，エー．; J Dominic Wallen; ウォレン，ジェイ．，ドミニク
Original assignee: MALIK M HASAN; Malik MHasan
Current assignee: MALIK M HASAN; Malik MHasan
Priority date: 2000-10-11
Filing date: 2007-11-07
Publication date: 2008-04-17
Anticipated expiration: 2021-10-11
Also published as: US8380537B2; US20080103832A1; US20170109478A1; US20120150557A1; AU1188902A; US20120290325A1; US7831446B2; US20120284057A1; US7664660B2; US20140122128A1; EP1328889A1; US20070203753A1; US20090119123A1; EP1328889A4; CA2734080A1; CA2734080C; US8229760B2; AR030878A1; US20100145732A1; CA2425603A1

Abstract

【課題】様々なフォーマットを持つ健康管理データを正規化し、関係者間でデータ交換するシステムを提供する。
【解決手段】第１コンピュータシステム１０、第２コンピュータシステム、および、規則エンジンで構成され、第１コンピュータシステム１０は、健康管理データを内部に保存する。第２コンピュータシステムは、第１コンピュータシステム１０と動作可能に結合し、第１コンピュータシステムから健康管理データを抽出するように構成される。規則エンジンは、この抽出された健康管理データを指定のフォーマットに正規化する。規則エンジンは、前記指定のフォーマットにおいて複数の健康管理データフィールド、ならびに正規化データのフィールド間の複数の関係を、定義する。
【選択図】図１

Description

（関連発明）
本願は、２０００年１０月１１日登録、「接続を確立する装置および方法」なる名称を持つ米国暫定特許申請書連番第６０／２３９，８６０号に関連し、かつ同申請書にたいする優先権を主張するものである。下記と重複しない限りにおいて、引用の明細書に開示される内容を、本申請書に含めることをここに明言する。

（発明の分野）
本発明は一般的に、健康管理サービスを実施する健康管理業界において、関わりのある当事者間に接続を確立するコンピュータシステムに関し、特に、本発明は、様々なフォーマットを持つ健康管理データを正規化し、かつ、生命保険業者と、保険加入者、例えば、健康管理サービスプロバイダー、患者や雇用者との間で正規化された形でデータを交換するためのシステムに関する。

（発明の背景）
健康管理とは情報産業と定義することが可能である。健康管理を斡旋したり、分配するために消費される時間と金の多くは、情報を創造し、回収し、利用するのに使われる。例えば、健康管理情報技術支援のために使われる出費は、１９９０年の約１０億ドルから２０００年の予定額２００億ドルに増加している。しかし、このような巨額を投資してもなお、現在の全健康管理出費のほぼ半分は、依然として患者ケアに直接関わらない活動のためであり、しかもその大部分は、自動化されていない情報支援に費やされていると考えられている。

患者ケアに直接関わらない活動に向けられる資金は、１９６０年代以来、健康管理業界に蔓延している。しかしながら、１９９０年代、医療費返還法の廃止や介護の発達と共に、医師や患者の態度や関心にも大きな変動が生じている。医療の実施や、そのような医療にたいする支払いについても現在では新しい規則が支配するようになっている。好ましい健康管理サービスプロバイダーの手配によるものであれ、様々な人頭税的手配によるものであれ、どのようなケアが可能か、どのケアにたいして誰が支払うのかを定めたり、また、処置の有効性を確かめるために適当な情報を確実に送るための、ケース管理、すなわち、「最良業務」の強化が為されているが、これが、現在、保険業者、健康管理サービスプロバイダーおよび患者の時間的・財政的資源の大部分を消費している。

プロバイダーや雇用主のような健康管理加入者は、各種健康保険業者から発行される多くの健康管理プランを定期的に処理する。しかしながら、これらの加入者は、保険企業からごく限られたやり方でしか情報を入手することができず、この情報の入手がしばしば重荷になっている。加入者は通常、保険業者との通信手段として、電話、ファックス、または、郵便しか持っていない。

特に悩ましいのは、金銭取引に関する情報、例えば、加入資格、保険請求（クレーム）、および、特典や、患者に関する基本的情報、例えば、医学検査や処方に関する情報が、保険業者からタイムリーに入手できるようにするにはどうしたらよいかということである。例えば、健康管理サービスプロバイダーは、提出用フォームを通じて保険業者から情報を求めたり、または、その業者に電話を掛けることがある。しかしながら、多くの場合、このような情報を求めたり受け取るのは、医療が実施され、患者がサービスプロバイダーの診察室を立ち去った後である。このために、患者の保険業者によって、認可されなかったり、カバーされなかったりするサービスの実施や、提供されるサービスの種類や出費額に影響を及ぼしかねないその他の結果を招くこととなる。

このように様々な困難があるが、その困難を生じるもう一つの理由として、最近の「支払い側」共同体の拡張が挙げられる。一時は、支払い側は、政府（連邦政府と州政府の両方）と、生命保険大手企業だけであった。現在では、自己保証プラン、ＩＤＮ、ＩＰＡやＰＰＯ、全面または部分割り当て保証、個人適合保証等、複雑な一連の系列が存在するので、被保険者に関する現在情報の利用者や、そのような現在情報にたいする需要が急増している。このような企業体の多くは、大小を問わず、相当額を情報システムに費やしている。しかしながら、このような情報システムを導入しているにも関わらずなお手動処理がかなり存在しており、そのためにクレーム当たりのコストはまだ相当のものがある。

更に、支払い側は、実行または追随するのが困難、または、不可能と感じさせるほどに複雑な規則を設けることによって、健康管理サービスプロバイダーや患者の怒りを買っている。この認識とは反対ではあるが、支払い側の方としても、健康管理サービスプロバイダー、患者、雇用主やその他の保険加入者にたいしてタイムリーに情報を提供することに関心を持っているのである。それでもなお、健康管理サービスプロバイダーのクレームの内相当パーセントが、多くの場合規則に必ずしも一致しないという理由で拒絶されている。このようなクレームには、再提出や、電話のやり取りや、その他費用のかかる手による介入が必要とされる。このような現在の処理体制におけるドル・コストは高い。事実、このために全面的仲介業が伸展を遂げており、これが、健康管理サービスプロバイダーに加入資格（特典資格ではない）証明サービスを供給して手数料を受け取っている。しかしながら、必要な証明手続きの多くは、このような仲介業者では全く実行不可能であり、また、行われたものでも、多くの場合我慢ができないほどに面倒で、従って費用がかかる。

多くの場合、照会承認はクレームよりもさらに複雑で、しかも、このような承認サービスは、一般に、従来の仲介業者からは得られない。例えば、健康管理サービスプロバイダーが処方を書く場合、その度ごとに、その保険業者の定めた、患者の生命保険プランにたいして特異的な形式に合わせて記入しなければならない。極めて多くの形式的手続きがあるので、薬剤処方も支払いを拒絶されることがよくあり、そのために、サービスプロバイダーおよび患者双方にとってさらに余分な作業が必要となる。同様に、医学検査は、特定の保険プランを支援するよう契約されている臨床検査室に送らなければならず、しかも、複雑な医学必要規則に合致して始めて支払いがなされる。

実際、健康管理サービスプロバイダーの多くは、やり取りを追跡し、請求書類を管理するための医業管理システムを持っている。しかしながら、これらのシステムのいずれも、様々な保険業者から送られる情報の全てを、サービスプロバイダーの利用可能な分かりやすい形で提供するという作業を達成できるほどには洗練されていない。

健康管理サービスプロバイダーばかりでなく、患者の方も、健康管理活動とは関係の無い、健康管理システムとのやり取りに時間の大部分を費やしている。この「無駄な」時間のほとんど全ては、適当な介入事象の時間設定、情報またはサービス受領のための待ち時間、または、承認、支払いや、所望のまたは必要な健康管理に関するその他の情報の入手に関係する。

大衆にたいする健康管理情報の一大供給源としてインターネットが出現した。インターネット利用者の相当部分がそれを、生命保険情報またはその管理のために利用している。特に、患者は、インターネットにおいて医学情報や、彼らの関心領域に関する解答を求めて検索する。事実、患者が、インターネットのウェブページから、プリントアウトや質問・推薦事項から成る長いリストで武装して、医師の診察室へ入っていくことはごく当たり前のことになっている。

残念ながら、インターネットの提供する接続性をもってすら、保険業者と患者の間での情報交換は見られない。患者にとって、その保険業者からもたされる情報の多くは、一般健康管理文献または、特定の健康支援グループに関わるデータベースからの自動配信によるものである。しかしながら、患者の保険計画の重要面は、単に正規化グループまたは支援グループの知識ばかりでなく、正常性、加入資格情報、照会承認、クレーム提出と支払い、試験、および、投薬のために保険業者の保険プランがどのような治療選択肢を用意しているか、である。前述のように、これらの機能性は、現在のシステムが自動化環境において取り扱うには複雑すぎる。個々の患者にたいする健康管理サービスプロバイダーや、保険プランにリンクした個人ベースの参照情報は、一般に入手不可能である。なぜなら、そのようなデータは幾つかのデータベースに存在し、しかも多くの場合、様々の、互いに不適合なフォーマットで書き込まれているので、そのデータを抽出・処理するには人の介入が必要とされるからである。このようにして、現在患者の取る解決法は、高額なドル出費となる、果てしない回数の電話のやり取りと、時間と、欲求不満である。

このような不適合性の生ずる一つの理由は、異なるデータベース間の接続性が考慮の対象となる以前に、各データベースが、そこのデータを使用する人々の個別的要求に合わせたことにある。様々のデータベースがそれぞれ異なるフォーマットを持った結果、どんな種類のコンピュータでも読み取りが可能な、均質データから成る、中央収納施設を供給することが不可能になっている。保険業者と、保険加入者との間の、広範な接続性を妨げるものはこの不適合性である。

当分野では、翻字プログラムやインターフェイスプログラムが知られている。あるフォーマットでデータを保持するプログラムを、別のフォーマットを持つコンピュータが翻字し読み込むことが可能である。しかしながら、このような翻字は、一つの不適合なフォーマットの一フィールドにおけるデータを、新しいフォーマットの標的フィールドに移動させるのに過ぎない。不適合フォーマットのデータが、適正な標的フィールドに移動したかどうかを確定することはできない。データを正規化する、すなわち、再構成すれば、そのデータを移動させるばかりでなく、データの意味を判断し、かつ、データを適正フィールドに設置することにもなる。

（発明の概要）
以上から、データベースとの適合性との有無を問わず、生命保険業者がそれを用いて、患者が健康管理サービスプロバイダーの外来を訪れる前に、または、訪れるのと同時に、特定の保険プランに関する情報を患者に供給するために、健康管理サービスプロバイダー、患者等と交信することが可能なシステムを供給することができるならば、それは有益であろう。この通信システムが、様々な保険業者を横断して接続し、そのために、例えば、健康管理サービスプロバイダーが、患者の加入するどのようなプランとも交信することが可能となるならばさらに有益であろう。また、互いに不適合なデータベース同士のデータを正規化することによって、加入資格や特典を決定したり、承認や事前確認を受領したり、クレームを提出したり、支払いを入手したり、クレーム問題を照会する自動化システムを、健康管理サービスプロバイダーが持つことができるならば、それも有益であろう。

本開示の例示の実施態様は、送信者から発せられた健康管理データを、受信者に通信するための装置を供給する。装置は、第１コンピュータシステム、第２コンピュータシステム、および、規則エンジンを含む。第１コンピュータシステムはその中に健康管理データを保存する。第２コンピュータシステムは、第１コンピュータシステムと動作可能に結合し、かつ、第１コンピュータシステムから健康管理データを抽出するように構成される。規則エンジンは、この抽出した健康管理データを、あらかじめ指定のフォーマットに正規化する。この規則エンジンは、指定フォーマットの中に複数の健康管理データフィールドを定義するばかりでなく、正規化データのフィールド同士の複数の関係も定義する。

更に幾つかの実施態様があるが、これらは、複数のコンピュータから成る第１コンピュータであって、各コンピュータがそれぞれ前記健康管理データの一部を保存する、そのような第１コンピュータを含む。この装置は更に、第２コンピュータシステムと動作可能に結合し、かつ、第２コンピュータシステムから正規化データを受信するように構成される第３コンピュータシステムを含んでいてもよい。規則エンジンは、第３コンピュータが、健康管理データ受信を承認されているかどうかを決定してもよい。

別の例示の実施態様は、一つのコンピュータシステムから別のシステムへ健康管理データを通信するための方法を供給する。この方法は、健康管理データを第１コンピュータシステムに保存する工程、第１コンピュータシステムから健康管理データを抽出し、この抽出データを第２コンピュータシステムへ通信する工程、この抽出データを、規則エンジンに従って指定のフォーマットに正規化する工程、および、この正規化データを第３コンピュータシステムに通信する工程、の諸工程を含み、ここに、規則エンジンは、指定のフォーマットの中に複数の健康管理データフィールドを定義し、かつ、正規化データのフィールド同士の複数の関係を定義する。

この例示の方法のさらに別の実施態様は、複数のコンピュータを含む第１コンピュータシステムを含み、ここで、保存工程は、前記１個を越えるコンピュータに健康管理データを保存することを含む。更に、第３コンピュータシステムは複数のコンピュータを含む。この健康管理データは、複数のデータベースにまたがって存在し、そのために、前記複数のデータベースのそれぞれが、第２コンピュータシステムと動作可能に結合することになる。

別の例示の実施態様は、送信者と受信者の間で健康管理データの交換を実行するシステムを供給する。本システムは、送信側コンピュータ、中間コンピュータ、規則エンジン、および、受信側コンピュータを含む。送信側コンピュータは健康管理データを保存する。中間コンピュータは、送信側コンピュータと動作可能に結合し、健康管理データを抽出するように構成される。この抽出データは、指定のフォーマットに正規化されて、規則エンジンに合致する正規化データを新規作成する。規則エンジンは、健康管理データの各フィールドを定め、各フィールドを、指定のフォーマットの対応フィールドに変換する。規則エンジンは更に、正規化データ同士を指定の指示内容に合致するようにするには、相互の関連付けをどのようにしたらよいかを定める。受信側コンピュータは、中間コンピュータと動作可能に結合する。受信側コンピュータは、第２規則エンジンで処理された正規化データを受信する。

さらに別の実施態様は、それぞれ健康管理データの一部を保存する複数のコンピュータから成る送信側コンピュータを含む。規則エンジンは、受信側コンピュータが健康管理データの受信を承認されているのかどうかを判断するようにしてもよい。受信者が健康管理サービスプロバイダーである場合、送信者と受信者の間で交換される正規化データは、加入資格／特典表示、メンバーリスト、クレーム提出、健康管理サービスプロバイダー一覧、書式一覧、診断コード一覧、処置コード一覧、オンラインアクセス健康管理プラン情報、オンライン通信健康管理プラン、患者とのオンライン通信、幾つかの保険プランにまたがる患者側データ、順序発生と追跡、および、結果総覧と発表、結果の印刷、処方書き込み、各患者における処方歴、患者の承認に基づく患者の個人的医学的記録へのアクセス、内容特異的およびオンデマンドによる個人の医学的内容と健康管理内容の統合、電子商取引−診察室、医学・健康管理関連製品知識・購買可能性、ｅメール、医業管理システム加入、病気治療支援、および、医師クレジット制加入、から成るグループから選ばれたものであってもよい。受信者が雇用者である場合、送信者と受信者の間で交換される正規化データは、団体加入資格、団体登録、登録変更、書式一覧、電子商取引統合、保険プランウェブサイトからのアクセスまたはＵＲＬを経由する直接アクセス、内容特異的およびオンデマンドによる個人的内容の統合、電子商取引統合、および、健康管理関連製品知識・購買可能性、を含むグループから選ばれたものであってもよい。

受信者が患者である場合、送信者と受信者の間で交換される正規化データは、ＩＤカード請求、住所変更、健康管理サービスプロバイダー総覧尋問、関心プロフィールに基づく個人の健康情報、診断情報、関連物品および患者教育資料、健康管理サービスプロバイダーおよび保険プランからの通信、臨床検査およびＸ線試験結果、健康管理サービスプロバイダーとの予約スケジュール、処方追加、個人の健康記録、加入資格／特典情報、クレーム情報、照会・承認情報および状況、健康管理サービスプロバイダー一覧、家系、薬剤処方歴、および書式一覧を含むグループから選ばれる。

本発明の別の例示の実施態様は、保険業者と加入者との間で交信される健康管理データを正規化するためのシステムを供給する。本システムは、保険業者システム、中間システム、および、加入者システムを含む。保険業者システムは、健康管理データを含む、少なくとも１個のデータベースを維持するように構成される。中間システムは、保険業者システムとデータベースに動作可能に接続され、保険業者システムのデータベースから健康管理データを抽出するように構成され、この健康管理データを、抽出データとして暫定データベースに保存する。この抽出データは、指定のフォーマットに正規化され、これによって、規則エンジンに合致する正規化データが新規作成される。規則エンジンは、この抽出データの各フィールドを指定のフォーマットに定義する。規則エンジンは更に、正規化データ同士を指定の指示内容に従って相互に関連付ける方式を定める。加入者システムは、中間システムと動作可能に結合し、規則エンジンで処理された正規化データを受信するように構成される。

例示のシステムのさらに別の実施態様は、複数のデータベースから成る、前記少なくとも一つのデータベースを、中間システムが、その複数のデータベースと動作可能に接続可能となるような形で含んでもよい。さらに加入者システムは請求を送信し、請求は中間システムに送られ、中間システムは、その請求に応答するために、どの健康管理データを抽出し、正規化するかを決める。加入者システムはまた前記請求を送信し、中間システムは前記正規化データをインターネットを介して送信してもよい。規則エンジンは、正規化データ同士の関係を、指定の指示内容に従って定義し、それによって請求にたいする応答を定めるようにしてもよい。中間システムはまた、抽出データが正規化される際に無効と特定された抽出データを除去するエラーデータ・システムを含んでいてもよい。中間システムは更に、中間システムの活動を追跡する監査データベースを含んでいてもよい。

本発明の別の例示の実施態様は、保険業者、臨床検査室、および、少なくとも一人の保険加入者の間で交わされる、医学検査実施のための健康管理システムを供給する。このシステムは、加入者コンピュータ、保険業者処理システム、規則データベース、および、検査室コンピュータを含む。医学検査依頼は、第一指定フォーマットに従って加入者コンピュータで実行される。保険業者処理システムは、この加入者コンピュータと動作可能に結合しており、かつ、それを介して医学検査依頼が送信される。処理システムは規則データベースと動作可能に結合しており、その医学検査依頼を所定の基準に従って承認する。検査室コンピュータは、この処理システムと動作可能に結合しており、規則エンジンに承認されるとこの医学検査依頼を受け容れる。医学検査結果は、検査室コンピュータから処理システムへ送信される。この結果は更に、検査室コンピュータに動作可能に結合する保険業者コンピュータに送信され、また、加入者コンピュータに送信される。

この例示のシステムのさらに別の実施態様としては、医学検査結果を、保険業者コンピュータに保存されるデータベースで読み込み可能な、第２指定フォーマットに変換する処理システムを含んでも良い。更に、少なくとも一人の保険加入者を、健康管理サービスプロバイダー、雇用者、および、患者から成るグループから選んでもよい。更に、医学検査請求および医学検査結果を、インターネットを通じて送信してもよい。

本システムのこれ以外の特長や利点は、下記の詳細な説明を考慮することによって当業者には明白となろう。ただし、この説明は、本発明を実行するに当たって、現在考えられるところの最善の方式を例示するものであるに過ぎない。
これら幾つかの図を通じて、対応する参照文字は、対応する部分を示す。本申請書に記載の例は、本発明の実施態様を例示するものであって、この例を、どのような意味においても本発明の範囲を限定するものと考えてはならない。

（発明の詳細な説明）
図１に示すもののような、本発明の例示の実施態様は、様々な保険業者１１が提供する複数のデータベースセット４，６，８を包含するシステム２を含む。各健康管理データベースセット４，６，８は、一つの保険業者データベース処理システム、または、一連の処理システムおよびデータベースを表すものと理解される。例えば、データベースセット４，６，ないし８はそれぞれ従来のコンピュータシステム、サーバー、ローカルエリアネットワーク（ＬＡＮ）、資産、または、一つ以上のデータベースを保存する他のコンピュータシステムを表していてもよい。データを送信するためには、システムはそのままで送信を実行する事が可能であるし、または、その機能を実行するために、別の一つのシステムが、データベースセット４，６，８のいずれかに付加されると考えられる。また、データベースセット４，６，８はそれぞれ、単一のデータベースを、または、それぞれが別々のデータベースフォーマットまたは言語を持つ、複数のデータベースを表すものと考えられる。

本願の目的のために、保険業者１１としてここで使用される「保険業者」という用語の言及は、ただ例示目的のためだけであると考えられる。この用語は、生命保険企業ばかりでなく、健康維持組織、自己健康管理基金、疾病管理組織、健康管理サービスプロバイダー株式会社、メディケア代行、並びに、健康管理データの保存・管理を実行する他の全ての組織を含む。「保険業者」という用語を、単に、健康保険企業や、その他の「支払い側」というようにその範囲を限定して考えてはならない。

従来、健康管理データは、保険業者の一台のコンピュータ、または、幾つかのデータベースを含む一連のコンピュータに保存されている。後者の場合、各データベースはしばしば独自のフォーマットで書き込まれており、各データベースフォーマットは他のデータベースフォーマットとは不適合であった。例えば、ある保険業者は、その保険データをあるフォーマットで保存しており、別の保険業者は、健康管理関連データを、前記フォーマットとは不適合な第２フォーマットで保存していることがある。更に、もっと問題なのは、同じ保険業者１１システム内部において、例えば、加入資格データは、ある特定のフォーマットのデータベースの中に存在し、その時のユーザーの要求に合致するように進化を遂げているが、一方、例えば、クレームデータは、ユーザーの要求に合致するフォーマットで別のデータベースに保存されているが、ただし、そのフォーマットは、加入資格データのフォーマットとは不適合という場合である。いずれの場合においても、本発明においては、いかなるフォーマットの健康管理データでも、共通の一つのフォーマットに正規化され、インターネット１２のような共通のネットワークを通じて保険加入者１３に配信され、加入者は、この正規化されたデータを用いて、健康管理関連取引や業務を遂行可能となる。更に、ここでは後述するように、様々なレベルのアクセスやセキュリティを設けることが可能であり、それによって、正規化データにアクセスする加入者１３は、その特定の使用または要求にとって必要でかつ適当とあらかじめ定められたデータにたいしてのみアクセス許可を受けられることが保証される。

図１が示すように、各データベースセット４，６，８から引き出されたデータは、特定の保険加入者１３によって読み込みが可能なフォーマットに正規化するデータ処理システム１０に伝達される。さらに具体的に言うと、データはインターネット１２を通じて、それと動作可能に接続する加入者１３のコンピュータ（単数でも複数でもよい）または端末（単数でも複数でもよい）に送信され、それらコンピュータまたは端末によって読み取られる。この加入者１３は、例示として、健康管理サービスプロバイダー１４、雇用者１６、および、患者１８、または、それらの任意の組み合わせを含む。加入者１３は更に、保険業者にデータまたは情報を請求する可能性のある、他の全ての、関心を持つ当事者を含むことが可能であり、そのような当事者としては、例えば、他の保険業者や疾病管理機関を含むと考えられる。

データベースセット４，６，８からのデータの送信は、加入者１３の内の誰かが、一台のコンピュータまたは複数のコンピュータを通じて請求を発信することによって開始する。請求２２は、インターネット１２を通じてデータ処理システム１０に送信され、同システムは、４，６または８のいずれか適当なデータベースセットから適当なデータを引き出す。このデータは共通のフォーマットに正規化され、この時点で請求２２にたいする応答２４が形成される。例えば、健康管理サービスプロバイダー１４が、保険受取人に代わって請求２２を出して、ある医学的処置にたいする支払いの承認を求める。この例では、応答２４を形成するために必要なデータは、例示的には、データベースセット４上に存在する加入資格、特典および請求データベースに存在する。応答２４を準備するために、データ処理システム１０は、必要なデータを判断し、問題のデータベースからそのデータを引き出す。次に、システム１０は、このデータを均一フォーマットに正規化し、さらに応答の性質はどのようなものでなければならないかを決める。この例では、応答２４は、その医学的処置にたいする支払いを認めるか、拒絶するかのいずれかである。システム１０は、正規化データを用いて応答を決め、次にこの応答は、保険サービスプロバイダー１４に送信され、かくしてこの取引は完了する。システム２は、任意の数の保険業者１１または加入者１３を含むことが可能であることを考慮しなければならない。特に、ここで後述するように、データ処理システム１０は、単一のまたは複数の加入者１３と、任意の単一のまたは複数の保険業者１１との取引を結びつけ、管理することが可能である。

システム２は、保険加入者１３にたいし、一般的には加入者１３と保険業者１１の間で取り交わされる請求２２、応答２４の形で表される、様々な保険取引上の選択肢を供給する。健康管理サービスプロバイダーにとって利用可能な取引の例としては、加入資格／給付表示、メンバーリスト、請求提出、健康管理サービスプロバイダー一覧、書式一覧、診断コード一覧、処置コード一覧、オンライン健康管理プラン情報アクセス、健康管理プランとのオンライン通信、患者とのオンライン通信、幾つかの健康管理プランにまたがる患者側データ、順序発生と追跡、および、結果考察と発表、結果の印刷、処方箋の記載、各患者にたいする処方歴、患者の承認に基づく患者の個人的医学的記録へのアクセス、内容特異的およびオンデマンドによる個人の医学的内容と健康管理内容の統合、電子商取引−診察室、医学・健康管理関連製品知識・購買可能性、ｅメール、医業管理システム加入、病気治療支援、および、医師クレジット制加入が挙げられる。

さらに別の例として、下記は、正規化データを利用して、健康管理サービスプロバイダー１４と保険業者１１の間で交わされる保険取引における具体的な記録とフィールドである。
記録：要約
フィールド
活動（日付）
照会
クレーム
試験結果
メンバー
米国人の健康の現状
特典記録
クレーム記録
患者記録
プロバイダー記録
あなたにピッタリの新プラン
記録：加入資格
フィールド
今日の患者
患者検索
性別
特典総合
メディケア・データ
患者リストに加える
氏名
開始日時
終了日時
生年月日
メンバーＩＤ
関係
ＰＣＰ
住所
都市名
州名
郵便番号
現在の特典
団体
負担者
特典プラン
記録：請求状態
フィールド
患者名
開始日時
終了日時
請求
請求番号
状態
プロバイダー名
患者名
メンバー番号
請求額
患者負担
支払額
サービス実施日
記録：請求詳細
フィールド
メンバー
プロバイダー
診断
注記
行数
ＤＯＳ
ＣＰＴ
詳細
修飾因子
場所
単位
状態
請求金額
承認金額
共同支払い
共同保証
割引
支払い
合計
記録：支払いの説明
フィールド
行数
状態注記
説明
チェック／日付
記録：専門家選択
フィールド
住所
都市名、州名、郵便番号
障害者アクセス
診察時間
連絡先
電話
ファックス番号
勤務時間後電話
性別
生年月日
専門
第２専門
患者受け入れ
一次健康管理サービス
委員会確認
言語
病院
病院特別待遇
ネットワーク
記録：追加請求
フィールド
健康保険
被保険者のＩＤ番号
患者の氏
名
ミドルネーム
患者の住所１
住所２
都市名
州名
郵便番号
患者の電話
生年月日
性別
被保険者との関係
既婚・未婚の区別
患者の雇用状態
仕事関連条件
自動車事故との関係
その他の事故との関係
被保険者の姓
患者の名
ミドルネーム
性別
生年月日
被保険者住所１
住所２
都市名
州名
郵便番号
電話
被保険者団体番号またはＦＥＣＡ番号
被保険者の雇用主／学校
被保険者の保険名
参照医師名
参照医師ＩＤ
外部検査室
外部検査室請求額
メディケイド再提出コード
メディケイド初回
前回承認番号
診断コード
項目
開始日付
終了日付
場所
種類
処置
修飾因子１
修飾因子２
診断Ｘ線指示
請求額
日数／単位数
患者
プロバイダー
開始日付
終了日付
診断１
診断２
診断３
診断４
処置ライン
ＣＰＴ
詳細
額
Ｄｘポインター
その他のエラー
合計額
請求額
承認額
共同支払額
割引額
年賦額
予想支払い額
記録：照会状態
フィールド
照会番号
患者（メンバーＩＤ）
有効期間（月数）
照会人請求者
照会先
患者リスト
照会人
照会先
照会番号
状態
記録：照会追加
フィールド
今日の患者
患者検索
専門家
専門家検索
プロバイダー
診断
患者
専門家
プロバイダー
診断
開始日
有効月数
依頼訪問数
理由
記録：処置と診断データ
フィールド
診断番号
診断名
処置コード
処置名
承認訪問数
患者
患者検索
照会先
専門家検索
照会人
診断
開始日
終了日
依頼訪問数
注記
依頼サービス
承認された補助サービス
記録：診断コード
フィールド
診断コード
ＤＸコード
診断コード注記
記録：処置コード
フィールド
処置コード（複数）
処置コード（単数）
処置注記
開始年齢
終了年齢
性別
場所コード
記録：薬剤療法クラスリスト
フィールド
治療クラス
クラス詳細
このクラスの薬剤数
記録：治療クラスで分類した処方リスト
フィールド
薬剤名
一般名
薬剤クラス
治療クラス
ＮＤＣ
記録：処方箋を書く
今日の患者
患者検索
プロバイダー
サービスの内容
薬剤処方
投薬
再処方
署名：サービス受益者
署名：サービス実施者
指示内容
選択薬局
記録：薬剤処方歴
フィールド
種類
薬剤処方
用量
頻度
理由
状態
記録：投薬処方中断
フィールド
種類
投薬処方
用量
頻度
理由
状態
記録：アレルギー
フィールド
アレルゲン
反応
開始日付
記録：医学検査注文
フィールド
患者ＩＤ
患者名
プロバイダーＩＤ
プロバイダー名
場所
検査室名
Ｄｘ
作用
バッテリー
試験
ＩＤ
種類
容量
日付
時間
採取者名
化学
血液学
毒物学／治療学
微生物学／ウィルス学
免疫学／血清学
尿分析／体液
処置
実施時間
優先順位
標本
警戒事象
記録：結果
フィールド
状態
注文番号
試験工程
警戒事象
注文日付
設備
患者
プロバイダー
日付／時間
処置
状態
指示値
日付／時間
実施済み
標本番号
種類
状態
結果
値
所望範囲

上に掲げた各フィールドは、データベースセット４，６または８のいずれに存在していてもよく、かつ、いずれのフォーマットまたは言語で書き込まれていてもよいデータを表す。もし何かの請求２２が発せされて、上記記録の内の一つ以上を要求した場合、データ処理システム１０は、そのデータを検索し、抽出し、かつ、それを正規化して、記録の中の適当なフィールドに出現するようにする。プロバイダー１４は、必要なら、そのデータを変更し、インターネット１２及びデータ処理システム１０を介して返信し、適当なデータベースセット４，６または８に保存させるようにする。

雇用者１６に利用が可能な取引の実例としては、団体加入資格、団体登録、登録変更、書式一覧、電子商取引（ｅコマース）統合、保険プランウェブサイトからのアクセスまたはＵＲＬを経由する直接アクセス、内容特異的およびオンデマンドによる個人の医学的内容と健康管理内容の統合、電子商取引（ｅコマース）統合、人的資源、事業（例えば、事務支給品）および、健康管理関連製品知識・購買実行性が挙げられる。

さらに別の例として、下記は、正規化データを利用して、雇用者１６と保険業者１１の間で交わされる保険取引における具体的な記録とフィールドである。
記録：自由登録
フィールド
健康保険
雇用者団体番号
姓（ラストネーム）
患者の名（ファーストネーム）
ミドルネーム
従業員住所１
住所２
都市名
州名
郵便番号
自宅電話
職場電話
一次言語
生年月日
性別
社会保障番号
一次診療医
慢性患者
扶養家族姓
名
ミドルネームのイニシャル
生年月日
性別
関係
社会保障番号
一次診療医
慢性患者
有効日付
雇用／再雇用日付
その他の生命保険証券
保険業者の名前と住所
その他の健康管理保証の有効日付
証券保持者の姓
名
ミドルネーム
保険証書／団体番号
メディケアによる保証
メディケア番号（単数または複数）
過去１８ヶ月内における健康保険
イエスならば、保険の種類、団体、個人、ＣＯＢＲＡ、メディケア／Ｃｈａｍｐｕｓ、変更または保証が終了したその他の理由
承認状を読んで同意すること
記録：登録−変更
フィールド
健康保険
雇用者団体番号
姓
名
ミドルネーム
従業員住所１
住所２
都市名
州名
郵便番号
自宅電話
職場電話
一次言語
生年月日
性別
社会保障番号
一次診療医
慢性患者
メンバー期間
扶養家族姓
名
ミドルネームのイニシャル
生年月日
性別
関係
社会保障番号
一次診療医
扶養期間
雇用／再雇用日付
有効日付
変更理由
名前
登録種類
注記

患者１８が利用可能な取引の例としては、ＩＤカード請求、住所変更、健康管理サービスプロバイダー一覧請求、メンバーの関心プロフィールに基づく個人の健康情報、並びに、保険プラン行政による診断情報および臨床情報、関連物品および患者教育資料、健康管理サービスプロバイダーおよび健康管理プランからの通信、オンラインの患者にたいする臨床検査およびＸ線結果、健康管理サービスプロバイダーとの予約スケジュール、照会状態、処方追加、教育資料、個人の健康記録（包括的既往歴の中に維持され医師がオンラインでそれを参照できる）、加入資格／特典情報の視覚的表示、クレーム情報の視覚的表示、照会・承認情報と状況、健康管理サービスプロバイダー一覧、個人健康記録、家系、投薬プロフィール、書式一覧、および、メンバーとプロバイダーの間での交信が挙げられる。

データ処理システム１０の構成を図２に示す。データベースセット４、６，８はそれぞれデータ接続性サブシステム２０に動作可能に接続される。データ接続性サブシステム２０は、データベースセット４，６，８を保存する様々なコンピュータシステム間で使用される、各種の接続性を受け容れるように構成される。他の実施態様では、データベースセット４，６，８のそれぞれの場所に個別のデータ処理システム１０を設け、それによって、各データ処理システム１０は、本申請書で後述するように、単一のデータベースセットにたいしてデータを正規化し、かつ、サーバー間通信を管理するようになっていることを考慮しなければならない。

図２には、データ抽出サブシステム２８も描かれている。サブシステム２８は、複数であることの方が多いデータベースの統合を管理する。データ抽出サブシステム２８はまた、図３を参照しながら後述するように、データベースセット中４，６，８の幾つかのデータベースにたいするデータアクセスを管理するロジックを含む。企業マスター個人インデックス（"ＥＭＰＩ"）が、このデータ抽出サブシステム２８に動作可能に結合する。ＥＭＰＩ３０は、システム２のおける全ての被保険者に関する、データベース横断性の視覚表示を提示する。ＥＭＰＩはまた、プロバイダー１４、雇用者１６、接続される患者１８の適正なＩＤを管理すると共に、必要に応じて、一意的な特異性を持つその他の実体をも管理する。インデックスデータベース３２はＥＭＰＩ３０によってサポートされる。具体的に言うと、インデックスデータベース３２は、特定データを相互に関連付けるための基盤となるインデックスを保存する。このインデックスデータベース３２は典型的には、ＥＭＰＩの上に構築され、ＥＭＰＩによって維持される。

事業目的サブシステム３４は、データの正規化や、保険業者１１と加入者１３の間においてそのデータの利用を推進するロジックルールを含む。このような能力を実行するためには、どのような特定状況においても様々の工程がサポートされる。例示として言うと、そのような工程としては、入力データについて、照会承認や許可確認が得られるかどうかを規則に基づいて評価したり；プロバイダーによって提出された請求について代行的または実際的判断を下し、かつ、同時に保険業者１１にたいして資金を発送したり、患者１８にたいして特典を説明したり；プロバイダー１４、雇用者１６および患者１８の区分けリストを発行したり；また、患者１８にたいして検査室結果をグラフ表示したり、統合型の請求に基づく保険記録を発行したり、ということが挙げられるが、ただしこれらに限定されない。

内容電子商取引サブシステム３６は、データ処理システム１０にたいして第三者能力を付与する。サブシステム３６の内容部分は、第三者所属内容、例えば、病気に関する記事、掲示、通知、ノート、および、その他の医学関連の参考文献の管理と統合を実行する。サブシステム３６の電子商取引部分は、付属の製品・サービス販売業者を抱えたショッピングカート型データベースを通じて行われる企業対企業、企業対消費者による購入を含めた、電子商取引能力を統合する。

個人化サブシステム３８は、前記サブシステム２０，２８，３４，３６からの情報を統合し、システム２におけるデータの個人化視覚表示を提供する。具体的に言うと、いずれかの加入者１３がシステムにログインして、データベースセット４，６または８のデータまたはその他の情報にアクセスすると、あるいは、内容／電子商取引サブシスム３６にアクセスした場合でも、視覚表示された種類から得られた関連情報や、購入した、または、検索された製品が、ユーザー固有データベース４０の中に保存される。従って、次のログインでは、特定のユーザーの見る情報は、その加入者に合った、さらに親しみやすい、関連性のある、有益なやり方で配置され、また、アクセスされることが可能となる。

表示サブシステム４２は、正規化データおよび情報を、患者１３にたいして表示可能なフォーマットで管理する。例えば、ワールドワイドウェッブは、インターネットユーザーにとってはお馴染みの目的地であるが、これは、ＨＴＭＬフォーマットで出力を受け入れ、かつ、従来のインターネットブラウザーによってアクセスが可能である。しかしながら、このデータは、ほとんどいかなる形式でも表示することが可能であり、従って様々なアクセスデバイス（例えば、モバイルデバイスのＷＡＰ）を受容することが可能である。

図２では、セキュリティサブシステム４４は、他のサブシステム２０，２８，３４，３６，３８，４２と統合されて示されている。セキュリティサブシステム４４は、幾つかのやり方でデータセキュリティを保持する。先ず、一つの実施態様では、保険業者１１のデータは、自身の現場データベースで維持され、保険業者自身１１によってコントロールされている。第２に、保険業者１１のデータは、請求２２がなされると、それが保険業者１１データベースから接続サブシステム２０に送信され、最終的に加入者１３に送信される際、暗号化される。第３に、加入者１３のブラウザーは、インターネット１２を通じてデータを視覚表示または発信するに当たって暗号化を含む。最後に、データ処理システム１０には内部的セキュリティが組み込まれてあり、知る必要のあるユーザーのみが、特定のデータ、例えば、クレームや紹介情報にアクセスできるようにする。例えば、プロバイダー１４は、関連保険業者のクレームや紹介情報にのみアクセスできるが、患者の個々のクレーム要約にはアクセスできない。同様に、雇用者１６は、その従業員のクレーム情報にはアクセスできるが、ある種の個人情報にはアクセスすることができない。

暗号法の例としては、キーがVeriSign社によって認証される１２８ビットのSecure Sockets Layer （ＳＳＬ）がある。このＳＳＬ暗号化は、インターネットを通じて加入者１３のブラウザーに移動するデータが、その二つの場所の間にあるいかなる者によっても解明不能であることを意味する。暗号化は、ユーザーパスワードの保存のためにも有用である。ユーザーパスワードが保存されたり、従来のクリアテキストとしてシステムに用いられることもない。加入者１３のブラウザーの一つから、インターネットを通じて、保険業者１１のコンピュータまたはサーバー内の一つに発信される場合、パスワードはＳＳＬによって保護される。一旦パスワードが目標の最終サーバーに達したならば、解読アルゴリスムが、このパスワードを保護フォーマットに変換する。従って、サーバーにアクセスできるという特権を持つ者も、最終処理的機能を持つアプリを持っている者も、決してユーザーパスワードを入手することはできない。

更に、暗号化は、保険業者１１のデータベースセット４，６または８からデータ処理システム１０へと向かう動作的接続において有用である。しかしながら、その接続が、真の点対点接続であるなら、保険業者１１のコンピュータまたはサーバ（データベースセット４，６または８）は、この動作的接続において、このような暗号化を必要としなくともよい。さらにまた、この暗号化は、例えば、ハードウェアまたはソフトウェア、仮想個人ネットワーク（ＶＰＮ）、または、データベースの中の暗号化プロトコールを用いることによって実行することも可能である。

システム２の保険業者１１や加入者１３個々の内部でも、またはそれら同士の間でも、データを限定可能とする幾つかのモードがある。例えば、セキュリティサブシステム４４は、加入者１３が、保険業者１１に請求または視覚表示を求めることのできる実際データを制限するようにしてもよい。この場合、保険機関は、自分らの供給したデータしか見ることができない。例えば、医師は、自分の患者のクレームデータしか見ることができない。別法として、セキュリティサブシステム４４は、加入者１３にたいするアクセスを制限して、ある特定のデータベースの、ある特定のスクリーン域の特定のフィールドにしかアクセスできないようにすることも可能である。例えば、スクリーンがクレームにおけるドル額にたいして設けられている場合、雇用者は、このドル額を見ることのできる人を制限したく思うかも知れない。この場合、他のユーザー、例えば、患者１８は、クレームの他の部分を見ることはできるかも知れないが、ドル額を見ることはできない。更に、セキュリティサブシステム４４は、どのスクリーンをどのユーザーにたいしてアクセス可能とするかという形で制限してもよい。このセキュリティレベルが、ユーザーにとってどのような機能性が利用可能であるかを定義することになる。例えば、システム２における患者１８は、プロバイダー１４によって提出されたクレーム提出スクリーンを見ることはできないかもしれないが、診断情報スクリーンや健康プラン事務スクリーンは見ることができる。ユーザーの関心事に基づく特注セキュリティも含まれてよい。このセキュリティ法によれば、保険業者１１または加入者１３は、前述の実例にたいしてセキュリティパラメータを設定することが可能となる。更に、このツールは、システムにたいするログインを加えることができるインターネットに基づくツールや、ある特定のユーザーがアクセスできる値やスクリーンを指定するインターネットツールとして使用が可能であることを考慮しなければならない。更に、このセキュリティ方策の一部または全てを、データ処理システム１２全体を通じて用いることも可能であることを考慮しなければならない。

図２に示す監査サブシステム４６も、セキュリティサブシステム４４と同様、他のサブシステム２０，２８，３４、３６、３８、４２と統合される。監査サブシステム４６は、全てのサブシステムの動作を追跡する。監査サブシステム４６によって生成された情報により、統制者は、システム２の動作について、問題がないかどうか、市場動向がどうかを監視することが可能となる。

データ抽出サブシステム２８、事業目的サブシステム３４の模式図を図３に示す。前述したように、データベースセット４，６，８によって表されるたくさんのデータベースは、様々なフォーマットのデータを含む。しかしながら、データを加入者１３の一人に転送するまえに、そのデータは、先ず、加入者１３のどのコンピュータによっても読み込みが可能な新規のフォーマットに、例えば、ＨＴＭＬフォーマットに書き改められる。従って、データは、データベースセット４，６，８のいずれかから「抽出」され、次に、加入者１３のコンピュータによって読み込まれるように「正規化」される。この抽出データは、参照番号４８によって示される。

データベース４，６，８の内のいずれかからの抽出データ４８は、暫定データベース５０にアップロードされる。この暫定データベースは典型的には、データ抽出サブシステム２８の一部である。規則エンジン５２は、データの正規化をコントロールする規則を定義し、また、正規化したデータをどのように使用するかそのやり方を定義するという、二重目的を果たす。５４における正規化工程の際に、規則エンジン５２は、データの意味を判断し、次にそのデータを正規化データとして適正なフィールドに挿入することによってデータを均質化する。規則エンジン５２はさらに必要ならデータを、正規化フォーマットによって指定される構造または外観に適合するように再構成する。簡単な例として、仮定上はデータベースセット６に存在する照会データベースにおいて、州名フィールドに「ニュージャージー州」という見出しを含んでいてもよい。このフィールドが加入者１３によって請求された場合、規則エンジン５２は、そのフィールドが抽出されるようにし、次に、そのフィールドの意味が正規化した州名フィールドの意味と合致するかどうかを判断し、一致するなら、５８で、そのフィールドを、正規化州名フィールドに変更する。更に、規則エンジン５２が、正規化された州名フィールドは２文字の略号でのみ表わされると指定した場合、「ニュージャージー州」というフレーズは再構成されて略号"ＮＪ"となる。これは、従来の翻字プログラムとは全く違っている。従来の翻字プログラムは、照会データベースの州名フィールドを、「州名フィールド」という題名を持つ別のデータベースのどれかのフィールドと単に合致させて、次にデータを転送するだけである。このようなプログラムは、州名フィールドの意味を判断することはできず、次にそれらの意味が合致するかどうかを判断することもできず、更に、データを適当な外観を持つように再構成することもできない。例えば、検査室酵素にたいするフィールドは、一つのデータベースでは摂氏で表され、別のデータベースでは華氏で表されるようなことがあるかも知れない。無数の同様データを含めて、このようなデータは、典型的には、それらの存在するシステムによって単位が揃えられている。翻字プログラムは、データ間のこのような単位の不統一を補償するものではない。本発明の開示においては、正規化の一部は、データの意味を判断し、それを同じ定義のフィールドに、ただし単一フォーマットにおいて配置する。

規則エンジン５２は更に、データが劣悪かどうか、無効かどうかを判断する。５４の正規化工程で劣悪または無効と判断されたデータは、無効データ・データベース５６に転送される。無効データは、検査および適当な補正活動のためにデータベース５６に置かれ、適当なら再び導入されて、正規化される。

更に、規則エンジン５２は、前述したように、請求者が、請求の対象であるデータを見るための許可を得ているかどうかを判断するためのセキュリティ４４を組み込んでいる。例えば、雇用者１６が、例えばデータベースセット８の上に存在するクレームデータを請求した場合、規則エンジン５２は、セキュリティ４４と共同して、雇用者１６が、請求の対象データを見るための許可を得ているかどうかを決定する。もし得ていないのであれば、規則エンジン５２は請求の実現を拒否する。

一旦データが変換され、正規化フォーマットに再構成されたならば、規則エンジン５２は、この正規化データをどのようにしたら使用可能となるかを定める。例えば、請求２２がプロバイダー１４から保険業者１１の一人に発せられて、患者１８の一人の胸部Ｘ線写真の許可を頼んだ場合、適正な応答２４は、規則エンジン５２が最初に抽出し、正規化した、様々な加入資格、クレーム、給付、および、個人の各種データを含むデータベースから得られるデータを参照することでもよい。一旦そのデータが正規化されれば、規則エンジン５２は、請求２２に応答する工程に着手する。規則エンジン５２は、その特定の保険業者１１が、胸部Ｘ線写真を、請求に応じて承認してもよいかどうかを判断するために定めた指定の規則に基づいて応答２４を決める。各保険業者１１において、あるいは各データベースセット４，６，８においても、特定の応答２４を出すに当たって、独自の一組の規則に従うようにすることも可能である。

図３に示す監査データベース６２は、５８における変換工程の間、情報を管理し、追跡を維持する。データ請求、応答および電子商取引提出物は全て監視し記録することが可能である。この監査追跡情報は監査データベース６２に保存され、性能特性およびセキュリティ特性を強化する。監査データベース６２は、図２に示すように、監査サブシステム４６と一体となることも可能であり、あるいは、データベース６２は、サブシステム４６とは独立して機能する、あるいはサブシステム４６に付加する形のスタンドアローン型システムであり得ることを考慮しなければならない。

本開示の一つの実施態様では、システム２は、保証問題や支払い問題に関する情報を交換するのみならず、患者医療の積極的管理を実行することを考慮しなければならない。例えば、図４に示すように、システム２の一部は、注文され、承認された医学テストの工程、および、提出された結果を示している。例えば、健康管理サービスプロバイダー１４は、インターネット１２を通じて、医学検査の注文を出す。この注文は、データ処理システム１０に伝えられる。この注文はさらに検査室７０に伝えられ、注文は、標本か患者のいずれかが到着した場合、必要とされる特定の情報を明らかにする。標本がプロバイダー１４によって採取された場合、注文は検査室７０を特定し、プロバイダー１４に情報を与え、標本が検査室７０に送られる前に適当な標識を施されるようにする。注文と標本を受け取ると検査室７０は、データ処理システム１０を介して、プロバイダー１４と適当な保険業者１３'の両方に、それぞれ参照番号７４，７６に示されるように、状態または結果を戻すようにすることも可能である。

本システムを、前記の説明においては、特定の手段、材料および実施態様を参照しながら説明してきたわけであるが、当業者であれば、簡単に例示のシステムの本質的な特性を確定し、各種用例や特性に合わせて様々な変更や修正を、本発明の精神や範囲を逸脱することなく実行することは可能であろう。本発明の精神や範囲は付属の特許請求項に記述される通りである。

図１は、健康管理データを正規化し、その正規化データを、何人かの健康管理業者および各種保険加入者の間で交換するためのシステムの模式図である。図２は、図１に示す正規化システムにおけるデータ処理システムの模式図である。図３は、図１に示す正規化システムにおける、データ抽出および事業目的サブシステムの模式図である。図４は、保険業者と加入者の間において交換される医学検査の健康管理システムの模式図である。

Claims

送信者からの健康管理データを受信者に通信する装置であって、
健康管理データを内部に保存する第１コンピュータシステム；
第１コンピュータシステムと動作可能に接続し、かつ、第１コンピュータシステムから健康管理データを抽出するように構成される第２コンピュータシステム；および、
抽出された健康管理データを、指定のフォーマットに正規化する規則エンジンであって、指定のフォーマットの中に複数の健康管理データフィールドと、正規化データのフィールド間の複数の関係と、を定義する規則エンジン；
を含む装置。
第２コンピュータシステムと動作可能に接続し、かつ、第２コンピュータシステムから正規化されたデータを受信するように構成される第３コンピュータシステムをさらに含むことを特徴とする、請求項１の装置。
前記第１コンピュータは、それぞれが前記健康管理データの一部を保存する複数のコンピュータであることを特徴とする、請求項１のシステム。
前記規則エンジンは、第３コンピュータが健康管理データの受信を許可されているかどうかを判断することを特徴とする、請求項２のシステム。
受信者が健康管理サービスプロバイダーであって、送信者と受信者の間で交換される前記正規化データは、加入資格／特典表示、メンバーリスト、クレーム提出、健康管理サービスプロバイダー一覧、書式一覧、診断コード一覧、処置コード一覧、オンラインアクセス健康管理プラン情報、オンライン通信健康管理プラン、患者とのオンライン通信、幾つかの保険プランにまたがる患者側データ、順序発生と追跡、および、結果総覧と発表、結果の印刷、処方書き込み、各患者における処方歴、患者の承認に基づく患者の個人的医学的記録へのアクセス、内容特異的およびオンデマンドによる個人の医学的内容と健康管理内容の統合、電子商取引−診察室、医学・健康管理関連製品知識・購買可能性、ｅメール、医業管理システム加入、病気治療支援、および、医師クレジット制加入、から成るグループから選ばれたものであることを特徴とする、請求項１のシステム。
受信者が雇用者であって、送信者と受信者の間で交換される前記正規化データは、団体加入資格、団体登録、登録変更、書式一覧、電子商取引統合、保険プランウェブサイトからのアクセスまたはＵＲＬを経由する直接アクセス、内容特異的およびオンデマンドによる個人的内容の統合、電子商取引統合、および、健康管理関連製品知識・購買可能性、から成るグループから選ばれたものであることを特徴とする、請求項１のシステム。
受信者が患者である場合、送信者と受信者の間で交換される正規化データは、ＩＤカード請求、住所変更、プロバイダー総覧検索、関心プロフィールに基づく個人の健康情報、診断情報、関連物品および患者教育資料、健康管理サービスプロバイダーおよび保険プランからの通信、検査室およびＸ線試験結果、健康管理サービスプロバイダーとの予約スケジュール、処方追加、個人の健康記録、加入資格／特典情報、クレーム情報、照会・承認情報および状況、プロバイダー一覧、家系、医薬処方歴、および書式一覧から成るグループから選ばれることを特徴とする、請求項１のシステム。
一つのコンピュータシステムから別のコンピュータシステムへ健康管理データを通信する方法であって、
第１コンピュータシステムに健康管理データを保存する工程；
第１コンピュータシステムから健康管理データを抽出し、この抽出データを第２コンピュータシステムへ通信する工程；
この抽出データを規則エンジンに従って指定のフォーマットに正規化する工程であって、ここに、規則エンジンは、指定フォーマットの中に複数の健康管理データフィールドと、正規化データのフィールド間に複数の関係を定義し、かつ、
この正規化データを第３コンピュータシステムに通信する工程、
を含む通信方法。
前記第１コンピュータシステムが複数のコンピュータを含み、かつ、前記保存工程が、前記複数のコンピュータの内、１個を越える数において健康管理データを保存することを特徴とする、請求項８の方法。
前記第３コンピュータシステムが複数のコンピュータを含むことを特徴とする、請求項８の方法。
前記健康管理データが、複数のデータベースにまたがって存在し、かつ、前記複数のデータベースのそれぞれが第２コンピュータシステムと動作可能に接続していることを特徴とする、請求項８の方法。
送信者と受信者の間で健康管理データを交信するシステムであって、
健康管理データが保存される送信側コンピュータ；
前記送信側コンピュータと動作可能に接続する中間コンピュータであって、ここに、前記中間コンピュータは健康管理データを抽出するように構成され；
前記抽出データを受信し、それを指定のフォーマットに正規化するように構成される規則エンジンであって、ここに、前記規則エンジンは、前記抽出データの各フィールドを定義し、各フィールドを、指定フォーマットの対応フィールドに変換し、正規化データを新規作成し、ここに、前記規則エンジンは更に、前記正規化データ同士を、指定の指示内容に一致して相互に関連付ける際、その関連付けの方法を定義し；および、
中間コンピュータと動作可能に接続し、前記正規化データを受信するよう構成される受信側コンピュータ、
を含むシステム。
送信側コンピュータは、それぞれが健康管理データの一部を保存する複数のコンピュータであることを特徴とする、請求項１２のシステム。
前記規則エンジンは、受信側コンピュータが健康管理データの受容を許可されているかどうかを決定することを特徴とする、請求項１２のシステム。
受信者が健康管理サービスプロバイダーである場合、送信者と受信者の間で交換される前記正規化データは、加入資格／特典表示、メンバーリスト、クレーム提出、健康管理サービスプロバイダー一覧、書式一覧、診断コード一覧、処置コード一覧、オンラインアクセス健康管理プラン情報、オンライン通信健康管理プラン、患者とのオンライン通信、幾つかの保険プランにまたがる患者側データ、順序発生と追跡、結果総覧と発表、結果の印刷、処方書き込み、各患者における処方歴、患者の承認に基づく患者の個人的医学的記録へのアクセス、内容特異的およびオンデマンドによる個人の医学的内容と健康管理内容の統合、電子商取引−診察室、医学・健康管理関連製品知識・購買可能性、ｅメール、医業管理システム加入、病気治療支援、および、医師クレジット制加入、から成るグループから選ばれたものであることを特徴とする、請求項１２のシステム。
受信者が雇用者である場合、送信者と受信者の間で交換される前記正規化データは、団体加入資格、団体登録、登録変更、書式一覧、電子商取引統合、保険プランウェブサイトからのアクセスまたはＵＲＬを経由する直接アクセス、内容特異的およびオンデマンドによる個人的内容の統合、電子商取引統合、および、健康管理関連製品知識・購買可能性、から成るグループから選ばれたものであることを特徴とする、請求項１２のシステム。
受信者が患者である場合、送信者と受信者の間で交換される正規化データは、ＩＤカード請求、住所変更、プロバイダー総覧検索、関心プロフィールに基づく個人の健康情報、診断情報、関連物品および患者教育資料、健康管理サービスプロバイダーおよび保険プランからの通信、検査室およびＸ線試験結果、健康管理サービスプロバイダーとの予約スケジュール、処方追加、個人の健康記録、加入資格／特典情報、クレーム情報、照会・承認情報および状況、プロバイダー一覧、家系、医薬処方歴、および書式一覧から成るグループから選ばれることを特徴とする、請求項１２のシステム。
保険業者と加入者の間を交信させる保険データの正規化システムであって、
前記保険データを含む少なくとも一つのデータベースを維持するように構成される保険業者システム；
前記保険業者システムおよび前記データベースと動作可能に接続する中間システムであって、ここに、保険業者システムのデータベースから保険データを抽出し、その保険データを、抽出データとして、暫定データベースに保存するように構成される中間システム；
前記抽出データを受信し、それを指定のフォーマットに正規化するように構成される規則エンジンであって、前記規則エンジンは、前記抽出データの各フィールドを定義し、各フィールドを、指定フォーマットの対応フィールドに変換し、正規化データを新規作成し、ここに、前記規則エンジンは更に、前記正規化データ同士を、指定の指示内容に一致して相互に関連付ける際、その関連付けの方法を定義し；および、
中間システムと動作可能に接続する加入者システムであって、ここに、前記加入者システムは、前記正規化データを規則エンジンに従って受信するよう構成されること、
を含むことを特徴とするシステム。
前記少なくとも一個のデータベースが複数のデータベースであり、前記中間システムは、この複数のデータベースに動作可能に接続されることを特徴とする、請求項１８のシステム。
前記加入者システムは請求を送信し、この請求は中間システムに送られ、中間システムは、請求にたいして応答するために、どの保険データを抽出し、正規化するかを決定することを特徴とする、請求項１８のシステム。
インターネットを通じて、前記加入者システムは請求を送信し、前記中間システムは正規化データを送信することを特徴とする、請求項２０のシステム。
前記中間システムは、抽出データが正規化される際に、無効とされた抽出データを除去するエラーデータ・システムを含むことを特徴とする、請求項１８のシステム。
前記無効と特定された抽出データが訂正され、再導入され、かつ、正規化されることを特徴とする、請求項２２のシステム。
前記中間システムは、該中間システムの活動を追跡するための監査データベースを含むことを特徴とする、請求項１８のシステム。
前記規則エンジンは、指定の指示内容に従って前記正規化データ同士の関係を定義し、それによって請求にたいする応答を定めることを特徴とする、請求項２０のシステム。
保険業者、臨床検査室および少なくとも一人の保険加入者の間で医学検査実施の健康管理を実行するシステムであって、
加入者コンピュータであって、そこにおいて医学検査請求が第１指定フォーマットに従って発せられる加入者コンピュータ；
加入者コンピュータに動作可能に接続し、それを通じて前記医学検査請求が伝送される保険業者処理システムであって、該処理システムは規則データベースに動作可能に結合し、指定の基準に従って前記医学検査請求を承認し；および、
前記処理システムに動作可能に結合し、前記医学検査請求を、それが規則エンジンによって承認された場合、受信する検査室コンピュータであって、医学検査の結果は検査室コンピュータから処理システムに送信され、該システムにおいて、前記結果が、検査室コンピュータに動作可能に結合される保険業者コンピュータ、および、加入者コンピュータに送信される、
を含むシステム。
前記処理システムは、医学検査の結果を、保険業者コンピュータのデータベースが読み取り可能な、第２の指定フォーマットに変換することを特徴とする、請求項２６のシステム。
前記少なくとも一人の保険加入者は、健康管理サービスプロバイダー、雇用者、および、患者から成るグループから選ばれることを特徴とする請求項２６のシステム。
前記医学検査請求および医学検査結果が、インターネットを通じて送信されることを特徴とする、請求項２６のシステム。