(57)【要約】  支払い処理ネットワークを通して患者情報を記憶し、この患者情報にアクセスするための方法が開示されている。本発明の一実施形態は、支払い処理ネットワークを介し、種々の医療機関から医療情報を収集するステップと、中央ロケーションに前記収集された医療情報を記憶するステップと、リクエスト時に、前記収集され、記憶された医療情報から特定の医療情報をリクエスト者に提供するステップとを備える。
2009541864.tif 000002
【特許請求の範囲】
【請求項１】
支払い処理ネットワークを介して種々の医療機関から医療情報を収集するステップと、
中央ロケーションに前記収集された医療情報を記憶するステップと、
リクエストに応じて、前記収集され、記憶された医療情報から特定の医療情報をリクエスト者に提供するステップとを備える、方法。
【請求項２】
前記医療情報は、患者情報、医療履歴、医療記録、検査結果、Ｘ線検査結果、放射線検査レポート、医療問題リスト、処方情報、アレルギー、血液型、免疫履歴、臨床カルテおよび保険情報および補償範囲を含む、請求項１に記載の方法。
【請求項３】
前記医療機関は、病院、薬局、検査機関、保険引受者およびプロバイダのオフィスを含む、請求項１に記載の方法。
【請求項４】
前記支払い処理ネットワークは、クレジットカードおよび金銭的な取引を処理するように構成されている、請求項１に記載の方法。
【請求項５】
リクエスト者は、医師、看護師、健康管理要員、薬剤師および保険業者を含む、請求項１に記載の方法。
【請求項６】
支払い処理ネットワークを介して種々の医療機関から医療情報を収集するコードと、
中央ロケーションに前記収集された医療情報を記憶するコードと、
リクエストに応じて、前記収集され、記憶された医療情報から特定の医療情報をリクエスト者に提供するコードとを備える、コンピュータで読み取り可能なメディア。
【請求項７】
請求項６に記載の、コンピュータで読み取り可能なメディアを含む、サーバー。
【請求項８】
支払い処理ネットワークを介して種々の医療機関から医療情報を収集する手段と、
中央ロケーションに前記収集された医療情報を記憶する手段と、
リクエストに応じて、前記収集され、記憶された医療情報から特定の医療情報をリクエスト者に提供する手段とを備える、システム。
【請求項９】
プロバイダのアクセスデバイスを使用し、医療情報をリクエストするステップを備え、前記リクエストされた医療情報は、支払い処理ネットワークを介して種々の医療機関から収集され、中央ロケーションに記憶されるようになっており、
更に前記医療情報を受信するステップを備え、前記リクエストされた医療情報は前記記憶された医療情報から提供される、方法。
【請求項１０】
前記プロバイダのアクセスデバイスは、ポイントオブセール（ＰＯＳ）デバイス、携帯電話、パーソナルデジタルアシスタント、パーソナルコンピュータ、タブレットパーソナルコンピュータ、ハンドヘルド特殊リーダー、セットトップボックス、電子キャッシュレジスタ、自動現金支払機、バーチャルキャッシュレジスタ、キオスクおよびアクセスシステムを含む、請求項９に記載の方法。
【請求項１１】
前記医療情報は、患者情報、医療履歴、医療記録、検査結果、Ｘ線検査結果、放射線検査レポート、医療問題リスト、処方情報、アレルギー、血液型、免疫履歴、臨床カルテおよび保険情報および補償範囲を含む、請求項９に記載の方法。
【請求項１２】
前記医療機関は、病院、薬局、検査機関、保険業者およびプロバイダのオフィスを含む、請求項９に記載の方法。
【請求項１３】
前記支払い処理ネットワークは、クレジットカードおよび金銭的な取引を処理するように構成されている、請求項９に記載の方法。
【請求項１４】
プロバイダのアクセスデバイスを使用し、医療情報をリクエストするコードを備え、前記リクエストされた医療情報は、支払い処理ネットワークを介して種々の医療機関から収集され、中央ロケーションに記憶されるようになっており、
更に前記医療情報を受信するコードを備え、前記リクエストされた医療情報は前記記憶された医療情報から提供される、方法。
【請求項１５】
支払い処理ネットワークを介してリクエストブローカーから医療情報のためのリクエストを受信するステップと、
支払い処理ネットワークを介して前記医療情報を前記リクエストブローカーに提供するステップとを備え、前記医療情報を中央ロケーションに記憶する、方法。
【請求項１６】
前記医療情報は、患者情報、医療履歴、医療記録、検査結果、Ｘ線検査結果、放射線検査レポート、医療問題リスト、処方情報、アレルギー、血液型、免疫履歴、臨床カルテおよび保険情報および補償範囲を含む、請求項１５に記載の方法。
【請求項１７】
前記支払い処理ネットワークは、クレジットカードおよび金銭的な取引を処理するように構成されている、請求項１５に記載の方法。
【請求項１８】
ポータブル消費者デバイスを使用し、医療情報をリクエストするコードを備え、前記リクエストされた医療情報は、支払い処理ネットワークを介して種々の医療機関から収集され、中央ロケーションに記憶されるようになっており、
更に前記医療情報を受信するコードを備え、前記リクエストされた医療情報は前記記憶された医療情報から提供される、方法。
【請求項１９】
請求項１８に記載の、コンピュータで読み取り可能なメディアを含むサーバー。
【請求項２０】
前記ポータブル消費者デバイスを使用し、医療情報をリクエストするステップを備え、前記リクエストされた医療情報は、支払い処理ネットワークを介して種々の医療機関から収集され、中央ロケーションに記憶されるようになっており、
更に前記医療情報を受信するステップを備え、前記リクエストされた医療情報は前記記憶された医療情報から提供される、方法。
【請求項２１】
ポータブル消費者デバイスは、クレジットカード、デビットカードおよび健康保険証を含む、請求項２０に記載の方法。
【請求項２２】
ポータブル消費者デバイスを使って医療情報をリクエストするステップを備え、このリクエストされる医療情報は、支払い処理ネットワークを介して種々の医療機関から収集され、中央ロケーションに記憶されるようになっており、
前記医療情報を受信するステップを備え、前記リクエストされた医療情報は前記記憶された医療情報から提供され、
前記ポータブル消費者デバイスを使って支払いリクエストを送るステップと、
支払いが認証されたことを示す認証応答メッセージを受信するステップとを備える、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願とのクロスレファレンス）
本願は、２００７年６月２０日に出願された米国非仮特許出願第１１／７６５，５５０号および２００６年７月２１日に出願された米国仮特許出願第６０／８１５，６１８号に基づく優先権を主張するものであり、上記米国特許出願全体を本願で参照として援用する。
【背景技術】
【０００２】
（背景）
医薬アレルギーまたは血液型のような患者の情報が不完全または不正確であることによって生じる過誤により、毎年、何十万人もの人の生命が脅かされている。健康管理の記録に対して正確で、かつタイムリーにアクセスできることは、患者の治療時の健康管理提供者（以下プロバイダと称す）による過誤を防止するのに役立つ。医療機関および関連する機関は、電子的に利用できる患者情報を有する結果、より安全な治療を行うことができ、コストを節約でき、患者情報に対してより効率的にアクセスすることが可能となると認識している。従って、多くの機関は、既に紙のファイルからデジタルファイルに切り換えており、それら特別な機関のためのコンピュータシステムを構築済みである。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
このことは、患者がその機関に留まっている場合、患者情報にアクセスするのに良好に働くが、患者が引っ越したり、健康保険を変えたりして、その保健機関を変えることがある。また、一人の患者が自分の健康管理の必要から、数種の機関を使用することがある。例えば患者が背中の痛みのために、まず最初の医師のところへ行き、この最初の医師は、背中の痛みのための薬の処方をし、患者に対して別の機関の専門医を紹介することがある。患者は、一般に別個の機関である薬局で、調合された処方薬を入手する。医師は、血液検査または他の検査機関の作業を要求することもあり、これら検査は、更に別の機関によって行われることがある。患者が専門医を訪問すると、患者は新しいフォーム上で医薬アレルギーをリストアップするために、自分のアレルギーを思い出し、検査機関の結果を持って行き、自分の最初の医師の過去の診断を思い出さなければならない。また、専門医が最初の医師からの種々の書類または電子ドキュメントを要求している間は、患者の予約が遅れることがある。
【０００４】
もしこれが緊急を要する状況である場合、より深刻な状態となり得る。患者が重大な事故に遭い、病院の緊急治療室に駆け込む場合、血液型および医薬アレルギーを判断したり、または患者の最初の医師からのこのような情報をリクエストするには時間がないことが多い。
【０００５】
従って、医療過誤を減らし、健康管理の質を改善し、コストを下げ、種々の健康管理機関および関連する機関からの患者情報および一般的な医療情報のプライバシーおよびセキュリティを高めるために、健康管理プロバイダが異なる患者健康サービスシステムにアクセスする必要があることが認識されている。本発明の実施形態は、上記およびそれ以外の課題を個々に、または総合的に解決するものである。
【課題を解決するための手段】
【０００６】
（簡単な概要）
本発明の実施形態は、種々の医療機関から患者の記録へのアクセスを安全かつ効率的に実行できるようにするための方法、システムおよびコンピュータで読み取り可能なメディアに関する。
【０００７】
本発明の一実施形態は、支払い処理ネットワークを介し、種々の医療機関から医療情報を収集するステップと、中央ロケーションに前記収集された医療情報を記憶するステップと、リクエスト時に、前記収集され、記憶された医療情報から特定の医療情報をリクエスト者に提供するステップとを備える、方法に関する。
【０００８】
本発明の別の実施形態は、プロバイダのアクセスデバイスを使用し、医療情報をリクエストするステップを備え、前記リクエストされた医療情報は、支払い処理ネットワークを介し、種々の医療機関から収集され、中央ロケーションに記憶されるようになっており、更に前記医療情報を受信するステップを備え、前記リクエストされた医療情報は、前記記憶された医療情報から提供される方法に関する。
【０００９】
本発明の別の実施形態は、支払い処理ネットワークを介し、リクエストブローカーから医療情報のためのリクエストを受信するステップと、支払い処理ネットワークを介し、前記医療情報を前記リクエストブローカーに提供するステップとを備え、前記医療情報を中央ロケーションに記憶する方法に関する。
【００１０】
本発明の別実施形態は、前記ポータブル消費者デバイスを使用し、医療情報をリクエストするステップを備え、前記リクエストされた医療情報は、支払い処理ネットワークを介し、種々の医療機関から収集され、中央ロケーションに記憶されるようになっており、更に前記医療情報を受信するステップを備え、前記リクエストされた医療情報は、前記記憶された医療情報から提供される方法に関する。
【００１１】
本発明の別実施形態は、ポータブル消費者デバイスを使って医療情報をリクエストするステップを備え、このリクエストされる医療情報は、支払い処理ネットワークを介し、種々の医療機関から収集され、中央ロケーションに記憶されるようになっており、前記医療情報を受信するステップを備え、前記リクエストされた医療情報は、前記記憶された医療情報から提供され、前記ポータブル消費者デバイスを使って支払いリクエストを送るステップと、支払いが認証されたことを示す認証応答メッセージを受信するステップとを備える、方法に関する。
【００１２】
以下本発明の上記およびそれ以外の実施形態について更に詳細に説明する。
【図面の簡単な説明】
【００１３】
【図１】本発明の一実施形態に係わるシステムのブロック図を示す。
【図２】本発明の一実施形態に係わる方法におけるステップを示すフローチャートである。
【発明を実施するための形態】
【００１４】
（詳細な説明）
本発明の実施形態は、健康管理のプロバイダ、例えば医師または看護師が、プロバイダのアクセスデバイスを使って、支払い処理ネットワークを通し、種々の医療機関、例えば病院、検査機関、薬局などで種々の健康記録に安全かつ効率的にアクセスできるようにするものである。
【００１５】
図１は、本発明の一実施形態で使用できるシステムを示す。説明を簡単にするために、１つのプロバイダと、１つのプロバイダのアクセスデバイス、１つのゲートウェイ、１つのリクエストブローカー、いくつかの医療機関、１人の発行者、１人のポータブル消費者デバイス、１人の消費者、１人の取得者および業者が示されている。しかしながら、本発明のこれら実施形態は多数のプロバイダ、ゲートウェイ、リクエストブローカー、医療機関などを含むことができる。更に本発明の一実施形態は、図１に示されているコンポーネントのすべてよりも少ないコンポーネントを含むことができる。更に図１のコンポーネントは、適当な任意の通信プロトコルを使って（インターネットを含む）任意の適当な通信媒体を介して通信することができる。
【００１６】
図１のシステムは、プロバイダ５と、このプロバイダに関連するプロバイダのアクセスデバイス１０とを備える。代表的な取引では、プロバイダ５はプロバイダのアクセスデバイス１０を使ってリクエストブローカー５０および支払い処理ネットワーク４０を介し、１つ以上の医療機関６０にて、患者情報をリクエストすることができる。リクエストブローカー５０は１つ以上の医療機関６０と作動可能な通信をすることができる。
【００１７】
プロバイダ５は、個人、例えば医師、看護師、健康監督要員、薬剤師、保険引受者などでよく、これらの者がプロバイダのアクセスデバイス１０を使用することができる。
【００１８】
プロバイダのアクセスデバイス１０は適当な任意の形態とすることができる。例えば適当なプロバイダのアクセスデバイスは、ポイントオブセールス（ＰＯＳ）デバイス、携帯電話、パーソナルデジタルアシスタント（ＰＤＡ）、パーソナルコンピュータ（ＰＣ）、タブレットＰＣ、ハンドヘルドの特殊なリーダー、セットトップボックス、電子キャッシュレジスタ（ＥＣＲ）、現金自動支払機（ＡＴＭ）、バーチャルキャッシュレジスタ（ＶＣＲ）、キオスク、アクセスシステムおよび同等物とすることができる。
【００１９】
非防御ゾーン（ＤＭＺ）３０は、安全支払い処理ネットワーク４０と別のネットワーク、例えばインターネットとの間のネットワークエリアとすることができる。このＤＭＸにゲートウェイ２０が常駐でき、このゲートウェイは処理および共用ライブラリーの組とすることができ、このライブラリーはリクエストを変換し、ネットワーク、例えばインターネットまたはモバイルネットワークを介して応答し、プロバイダ５０との間でメッセージの接続およびデリバリーを取り扱う。
【００２０】
リクエストブローカー５０はメッセージルーティングをサポートし、データを整理し、分散取引をサポートするためのソフトウェアまたはハードウェアとソフトウェアとの組み合わせとすることができる。リクエストブローカー５０は、医療機関６０のような最初のソースからのオリジナルデータをコピーしたデータの集合を提供する、ネットワーク上のデータ記憶装置とすることができる中央キャッシュ５５を使用できる。中央キャッシュ５５に記憶できる代表的なタイプのデータは、一般的な患者情報（氏名、住所など）、患者の医療履歴および記録、検査機関の結果、Ｘ線検査の結果、放射線検査の結果、医療問題のリスト、処方情報、アレルギー、血液型、免疫履歴、臨床カルテ、例えば患者に関する医師および看護師の関係、保険情報およびカバーなどの情報を含むことができる。
【００２１】
リクエストブローカー５０にリクエストがなされた後に、中央キャッシュ５５にデータを格納してもよく、１つ以上の医療機関６０から情報が取得される。定期的（例えば毎日、毎週、毎月）に、各医療機関６０からのバッチアップロードにより中央キャッシュ５５にデータが格納されるようにしてもよい。
【００２２】
中央キャッシュ５５は、性能および利用性を改善するためにレファレンスのローカリティを更に提供できる。インデックスを設けるのではなく、リクエストブローカー５０に中央キャッシュ５５を設け、各医療機関６０にリモートキャッシュを設けるほうが安価であり、高速であり、かつ信頼性があり、セキュリティおよびプライバシーのために良好である。安価である理由は、どの医療機関６０にも機器およびスペースを設けるのと異なり、中心ロケーションで中央キャッシュ５５のための機器および記憶スペースを利用できればよいからである。より高速で、かつ信頼できる理由は、オリジナルデータを再フェッチするよりもキャッシュされたコピーにアクセスするほうが、データを取得するのにかかる平均アクセス時間を短縮できるからである。セキュリティおよびプライバシーのために良好である理由は、中心ロケーションだけでセキュリティを実現すればよく、このほうがセキュリティが侵されるロケーションを少なくできるからである。更に、より安全である理由は、極めて安全かつプライベートな金融取引に使用される、一般にプライベートネットワークセグメントとなっている支払い処理ネットワーク４０内に常駐できるからである。
【００２３】
集中システムでは中央キャッシュ５５を有するリクエストブローカー５０は、単一のロジカルインスタンスであり、このロジカルインスタンスは、必要とされるサービスレベルに応じて単一の物理的インスタンスでもよいし、または冗長でもよい。分散システムでは、中央キャッシュ５５を有するリクエストブローカー５０を多数のロジカルインスタンスとすることができる。集中システムまたは分散システムのあるバージョンでは、大スケールの設置性能および利用可能性を改善するために、中央キャッシュ５５を有するリクエストブローカー５０を（例えば地域ベースで）論理的に分散させてもよい。
【００２４】
医療機関６０は、病院、薬局、検査機関、保険引受者、プロバイダなどでよく、すなわち患者の記録および情報のためのデータソースとすることができる。
【００２５】
支払い処理ネットワーク４０は、一般にプライベートなネットワークセグメントである安全なネットワークエリアとなっている。この支払い処理ネットワークは、認証サービス、例外ファイルサービスおよび清算および決済サービスをサポートし、デリバーするのに使用されるデータ処理サブシステム、ネットワークおよびオペレーションを含むことができる。支払い処理ネットワークの一例として、ＶｉｓａＮｅｔ（登録商標）を挙げることができる。このＶｉｓａＮｅｔ（登録商標）のような支払い処理ネットワークは、クレジットカード取引、デビットカード取引およびその他のタイプの商業的取引を処理することができる。特にＶｉｓａＮｅｔ（登録商標）は、認証リクエストを処理するＶＩＰシステム（Ｖｉｓａ統合支払いシステム）および清算および決済サービスを実行するベースＩＩシステムを含む。支払い処理ネットワーク４０は、インターネットを含む任意の適当な有線ネットワークまたは無線ネットワークを使用できる。一般にこのタイプの支払い処理ネットワークは、安全な金融取引のために使用されている。患者の健康情報に関係する取引は、安全かつ効率的でもなければならないので、健康サービス情報のためにこのタイプのネットワークを使用することが、理想的である。
【００２６】
図１は、商業的取引のために支払い処理ネットワーク４０の機能を示すために、発行者７６、消費者８０、ポータブル消費者用デバイス８５、取得者７０および業者７８も示している。取得者７０は、一般に商業的口座を有する銀行であり、発行者７６も銀行でよいが、小売店のようなビジネス事業体でもよい。取得者かつ発行者である事業体も存在する。消費者８０は、商品またはサービスを購入できる個人または営業体のような機関でよい。業者７８は、商品およびサービスを提供できる個人または営業体のような機関でよい。
【００２７】
ポータブル消費者デバイス８５は、任意の適当な形態でよい。例えば適当なポータブル消費者デバイスは、消費者の書類入れおよび／またはポケットにフィットできるよう（すなわちポケットサイズである）よう、手で持つことができ、コンパクトなものとすることができる。これらデバイスは、スマートカード、（マイクロプロセッサを含まず、磁気ストライプを有する）通常のクレジットカードまたはデビットカード、（エクソン−モービル社から市販されているＳｐｅｅｄｐａｓｓ（登録商標）のような）キーチェーンデバイスなどを含むことができる。ポータブル消費者デバイスの他の例として、携帯電話、パーソナルデジタルアシスタント（ＰＤＡ）、ページャー（呼び出し器）、支払いカード、セキュリティカード、アクセスカード、スマートメディア、トランスポンダおよび同等物を挙げることができる。ポータブル消費者デバイスはデビットデバイス（例えばデビットカード）、クレジットデバイス（例えばクレジットカード）または価値が記憶されているデバイス（例えば価値が記憶されているカード）でもよい。
【００２８】
ポータブル消費者デバイス８５は、一般に標準化されたプロトコルまたはデータ転送機関（例えばＩＳＯ１４４４３／ＮＦＣ）に従って、近接通信（ＮＦＣ）能力（または近接通信メディア）を使ってデータを転送し、受信できる無接触要素も含むことができる。近接通信能力とは、ポータブル消費者デバイス８５と支払い処理ネットワーク４０との間でデータを交換するのに使用できる近距離通信能力、例えばＲＦＩＤ、ブルートゥース（登録商標）、赤外線または他のデータ転送能力のことであり、この能力を使ってポータブル消費者デバイス８５と業者７８との間でデータを更新できる。従って、ポータブル消費者デバイス８５は、近接通信能力を介し、データおよび／または制御命令を伝送し、転送することができる。
【００２９】
代表的な購入取引では、消費者８０はポータブル消費者デバイス８５、例えばクレジットカードを使って業者７８のもとで商品またはサービスを購入する。消費者のポータブル消費者デバイス８５は、業者７８におけるＰＯＳ（ポイントオブセール）ターミナルのようなアクセスデバイスと相互対話できる。例えば消費者８０は、クレジットカードを取り出し、ＰＯＳターミナル内の適当なスロットにクレジットカードを通させる。これとは異なり、ＰＯＳターミナルは無接触リーダーでもよく、ポータブル消費者デバイス８５は無接触カードのような無接触デバイスでもよい。
【００３０】
次に、取得者７０へ認証リクエストメッセージが転送される。この認証リクエストメッセージを受信した後に支払い処理ネットワーク４０へ認証リクエストメッセージが送られる。支払い処理ネットワーク４０は次に、この認証リクエストメッセージをポータブル消費者デバイス８５の発行者７６へ転送する。
【００３１】
発行者７６が認証リクエストメッセージを受信した後に、発行者７６は認証応答メッセージを支払い処理ネットワーク４０へ戻すように送り、そのときの取引が認証されたかどうかを示す。次に支払い処理ネットワーク４０は、認証応答メッセージを取得者７０へ戻すように転送する。次に取得者７０は、応答メッセージを業者７８に戻すように送る。
【００３２】
業者７８が認証応答メッセージを受信した後に、業者７８におけるアクセスデバイスは消費者８０のための認証応答メッセージを提供できる。この応答メッセージは、ＰＯＳターミナルによってディスプレイしてもよいし、またはレシート上にプリントアウトしてもよい。
【００３３】
一日の終わりに、支払い処理ネットワーク４０により通常の清算および決済プロセスを実行できる。清算プロセスとは、消費者の口座へのポスティングおよび消費者の決算状態の調整を容易にするために、取得者と発行者との間で金銭的な詳細を交換するプロセスのことである。清算と決済は同時に行うことができる。
【００３４】
図２は、本発明の一実施形態に係わる一般的な方法を含むフローチャートを示す。図１のブロック図を参照し、この方法について説明できる。
【００３５】
最初に、プロバイダ５０は１つ以上の医療機関６０（例えば病院、検査機関）から患者情報（例えば医療記録、検査機関の結果）をリクエストするために、プロバイダのアクセスデバイス１０を使用できる。プロバイダ５は、特定の記録、例えば最近の検査機関の結果または医薬のアレルギー情報をリクエストしてもよいし、またはプロバイダ５は、患者の記録および医療履歴のすべてをリクエストしてもよい。患者はポータブル消費者デバイス８５、例えば保険カード、保険管理情報カード、クレジットカード、デビットカードなど、または１つのクレジットカードに数個のすべての機能、例えばクレジットおよび／またはデビット能力、保険情報、識別および健康管理情報を有する多機能カードを有することができる。プロバイダのアクセスデバイス１０は、デスクトップコンピュータまたはハンドヘルドのモバイルデバイスでよく、このコンピュータまたはデバイスにプロバイダ５は患者情報（例えば患者の氏名または医療記録番号）をマニュアルでプロバイダのアクセスデバイス１０に入力できる（ステップ２００）。別の例では、プロバイダのアクセスデバイス１０は、ＰＯＳでよく、患者情報をマニュアルで入力する代わりに患者のポータブル消費者デバイス８５がＰＯＳターミナルと相互対話してもよい。例えばプロバイダ５は、ＰＯＳターミナル内の適当なスロットに患者のカードを通すことによって患者情報をリクエストできる。この方法とは異なり、ＰＯＳターミナルを無接触リーダーとすることができ、患者情報を無接触カード内に入れてもよい。
【００３６】
プロバイダアクセスデバイス１０は、以下プロバイダクライアントと称す、プラグインのようなプログラムを含むことができる。このプラグインクライアントは、患者情報リクエストの有効性を判断すること、支払い処理ネットワーク４０を通し、リクエストブローカー５０を介して医療機関６０から情報をリクエストすること、および医療機関６０からの応答に対し、セキュリティおよび暗号解読を行うことなどの機能をプロバイダアクセスデバイス１０が実行できるようにするソフトウェアとすることができる。
【００３７】
プロバイダクライアントはプロバイダ５が入力した情報を有効にする（ステップ２１０）。情報が有効でない場合、リクエストが無効である旨をプロバイダ５に警告し、患者情報を再入力することをプロバイダ５に促すためのメッセージをプロバイダアクセスデバイス１０にディスプレイする。例えば「リクエスト無効。患者情報を再入力してください」なるメッセージをプロバイダアクセスデバイスにディスプレイできる。
【００３８】
プロバイダ５がプロバイダアクセスデバイス１０に入力した情報が有効となれば、プロバイダクライアントはリクエストをフォーマット化しゲートウェイ２０に接続する。プロバイダクライアントおよびゲートウェイ２０は、互いに認証し合い、ゲートウェイ２０へリクエストをパスする。
【００３９】
ゲートウェイ２０はプロバイダアクセスデバイス１０からのリクエストを受信し、このリクエストを支払い処理ネットワーク４０内のリクエストブローカー５０へパスする（ステップ２２０）。プロバイダクライアントによるリクエストの有効化の別の手段（またはその有効化に加え）、リクエストブローカー５０はリクエストが有効であるかどうかをチェックできる。リクエストが有効でなければ、リクエストが無効である旨をプロバイダ５に警告するためのメッセージを、ゲートウェイ２０を介してプロバイダアクセスデバイス１０に戻すことができる。例えば「リクエスト無効。患者情報を再入力してください。」なるメッセージをプロバイダアクセスデバイスにディスプレイできる。
【００４０】
リクエストが有効であれば、リクエストブローカー５０は、患者情報を含むことができる患者に関連した医療機関６０のリストであるルーティングマップを構築する。リクエストブローカー５０はルーティングマップ内の各々の医療機関６０に最新の一致があるかどうか、中央キャッシュ５５をチェックする。最新の一致がある場合、リクエストブローカーはその医療機関６０からの情報をリクエストする必要はなく、その代わりに中央キャッシュ５５に既に記憶されている情報を利用できる。最新の一致がなければ、リクエストブローカー５０はリクエストをフォーマット化し、そのリクエストを医療機関６０へ送り（ステップ２３０）、医療機関６０からの応答を待つ。
【００４１】
リクエストの間に依存関係がなければ、非同期収集が可能であり、このことは、リクエストブローカー５０が任意の順序で医療機関６０から戻された応答を受けることができることを意味する。リクエストの間に依存関係がある場合、同期収集が好ましい。任意の順序で医療機関６０からの応答を受信する代わりに、リクエストブローカーはルーティングマップ内の各医療機関６０ごとに、医療機関６０に接続し、リクエストを送り、応答を待つことができる。医療機関６０からの応答が受信された場合（または応答がないためにタイムアウトした場合）、リクエストブローカー５０は、各１つを処理するまでセッションをドロップし、次の医療機関６０を処理する。
【００４２】
リクエストブローカー５０が、割り当てられた時間（例えば数秒）内に医療機関６０からの応答を受信しなかった場合、そのリクエストはタイムアウトし、新しいリクエストをフォーマット化し、送る。別のソースを利用できる場合、別のソースに問い合わせする。リクエストブローカー５０は、多数回の試行（例えば３回の試行）の後に医療機関６０にリクエストすることを停止し、失われたデータに対して「利用不可」なるプレースホルダー（ｐｌａｃｅ  ｈｏｌｄｅｒ）を供給する。
【００４３】
医療機関６０は、情報のためのリクエストを受信し、このリクエストを処理し、応答をリクエストブローカー５０に戻すようにパスする（ステップ２４０）。
【００４４】
リクエストブローカー５０が（非同期収集または同期収集のいずれかで）医療機関６０から戻された応答のすべてを受信すると、リクエストブローカー５０はこれら応答を中央キャッシュ５５に記憶し、応答を集める（ステップ２５０）。リクエストブローカー５０は種々のタイプの応答を取り扱うことができる。例えば応答を不透明にすることができる。このことは、リクエストブローカーは応答のコンテンツを見ることができないことを意味する。不透明応答を暗号化することも可能である。応答が不透明でない場合、リクエストブローカーは応答に対し、価値を増したサービスを実施することもできる（ステップ２５０）。価値を増したサービスは、編集、増強および／または正規化とすることができる。これら応答をゲートウェイ２０へ送り、ゲートウェイ２０は応答をプロバイダアクセスデバイス１０上のプロバイダクライアントへパスする（ステップ２６０）。プロバイダクライアントは応答を受信し、不透明セグメントを解読し、データをプロバイダ５０へ提示する（ステップ２７０）。このデータは、プロバイダアクセスデバイス１０にディスプレイされる。
【００４５】
より詳しい例では、患者は自分の医師のところに行き、年に一度の定期検診を受け、医師は患者にコレステロールに関する検査をするために血液検査を受け、検査結果について話し合うために１週間以内に再来院するようアドバイスする。次に患者は、検査をしてくれる別個の機関である検査機関へ行く。患者が次の予約に従って医師を再訪問した場合、医師はマニュアルで自分のコンピュータに患者の氏名および／または医療記録の番号を入力するか、または患者がクレジットカードまたは保険証を有する場合にはＰＯＳターミナル内のスロットを通るようにカードをスライドさせて、患者の医療記録および患者が受けた血液検査の結果をリクエストする。上記とは異なり、ＰＯＳターミナルは無接触リーダーでもよく、患者の情報は無接触カード内にあってもよい。
【００４６】
医師が不正確な患者情報を入力した場合、医師は情報が正しく入力されなかった旨のメッセージを自分のコンピュータスクリーンまたはＰＯＳデバイス上で受けることになる。医師は情報を再入力するか、または患者のカードを再度スライドすることができる。
【００４７】
情報が一旦正しく入力されると、ゲートウェイを通してリクエストブローカーにリクエストを送り、リクエストブローカーは支払い処理ネットワークを介した、リクエストされたすべての情報の取得を取り扱う。リクエストブローカーは、リクエストされた情報を有する各医療機関、例えば患者が血液検査を受けた検査機関などの機関からの患者情報をリクエストする。リクエストブローカーは、まず情報が最近リクエストされたかを見るために中央キャッシュをまずチェックする（もしかすると医師は、患者との予約日前に検査結果を検討しているかもしれない）。情報が中央キャッシュ内にある場合、リクエストブローカーは中央キャッシュから直接応答を戻すことができる。そうでない場合、リクエストブローカーは検査機関に対して直接リクエストする。リクエストブローカーが検査機関からの応答を入手すると、リクエストブローカーはその応答を次に迅速に検索できるよう、その応答を中央キャッシュに記憶し、支払い処理ネットワークおよびゲートウェイを通して、その応答を医師に戻す。医師は次に、自分のコンピュータスクリーンまたはＰＯＳデバイスにディスプレイされている患者の記録を検討し、患者と共にその検査結果を入念に調べることができる。
【００４８】
患者はプロバイダ５からの治療を受ける前に、自己負担金（ｃｏｐａｙ）を支払うためにポータブル消費者デバイス８５を使用することもできる。このポータブル消費者デバイス８５は、クレジットカードまたはクレジットカードと組み合わされた保険証でもよい。患者は治療の時点でプロバイダ５にクレジットカードまたは保険証を提示できる。プロバイダ５は、上記のように患者情報（例えば患者の保険プロバイダからの自己負担支払額および／または一般的な患者の記録をリクエストし、および／またはＰＯＳターミナル内の適当なスロット内に患者のクレジットカードまたは保険証をスライドすることにより、患者の自己負担支払額を支払うために、ポータブル消費者デバイス８５を使用することができる。これとは異なり、ＰＯＳターミナルは無接触リーダーでもよいし、患者情報は無接触カード内にあってもよい。
【００４９】
患者に関連する医療機関からの情報に対するリクエストは、上記のような同じプロセスを経る。自己負担金の支払いをするためにポータブル消費者デバイス８５を使用する場合、ゲートウェイ２０を介して支払い処理ネットワーク４０へ支払いリクエストを送る。次に支払い処理ネットワーク４０はポータブル消費者デバイス８５の発行者７６に支払いリクエストメッセージを転送する。
【００５０】
発行者７６が支払いリクエストメッセージを受信した後に、発行者７６はそのときの取引が認証されるか否かを示すための認証応答メッセージを支払い処理ネットワーク４０に戻すように送る。次に、支払い処理ネットワーク４０は、ゲートウェイ２０を介してプロバイダ５に認証応答メッセージを戻すように転送する。
【００５１】
プロバイダ５が認証応答メッセージを受信した後に、プロバイダ５側のプロバイダアクセスデバイス１０は、患者に対する認証応答メッセージを提供できる。この応答メッセージはＰＯＳターミナルにディスプレイしてもよいし、レシートにプリントしてもよい。
【００５２】
一日の終わりに、支払い処理ネットワーク４０により、通常の清算および決済プロセスを実行できる。清算プロセスとは、消費者の口座に対するポスティングおよび消費者の決済状態の調整を促進するよう、取得者と発行者との間で金銭的な詳細を交換するプロセスのことであり、この清算と決済とは同時に行うことができる。
【００５３】
上記のような本発明はモジュラー態様または統合された態様でコンピュータソフトウェアを使用する制御ロジックの形態で実現できると理解すべきである。本明細書に記載した開示および教示内容に基づけば、当業者であれば、ハードウェアおよびハードウェアとソフトウェアの組み合わせを使用して本発明を実現するための別の方法について想到することができよう。
【００５４】
本願に記載したソフトウェアコンポーネントまたは機能のいずれも、適当な任意のコンピュータ言語、例えば従来の技術またはオブジェクト指向の技術を使用するＪａｖａ（登録商標）、Ｃ＋＋または、Ｐｅｒｌを使用するプロセッサによって実行すべきソフトウェアコードとして実現できる。このソフトウェアコードは、コンピュータが読み取りできるメディア、例えばランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、磁気メディア、例えばハードドライブまたはフロッピー（登録商標）ディスク、もしくは光媒体、例えばＣＤ−ＲＯＭ上の一連の命令またはコマンドとして記憶することができる。かかる任意のコンピュータで読み取りできるメディアは、単一の計算装置上またはその内部に常駐でき、システムまたはネットワーク内の異なる計算装置上またはその内部に存在できる。
【００５５】
これまでの記載は説明のためのものであり、限定的なものではない。当業者がこの開示を検討すれば、本発明の多数の変形例が明らかとなろう。従って、本発明の範囲は上記記載を参照して決定すべきではなく、むしろ本発明の全範囲または均等物と共に、係属中の特許請求の範囲を参照して決定すべきである。
【００５６】
本発明の範囲から逸脱することなく、任意の実施形態からの１つ以上の特徴事項を他の任意の実施形態の１つ以上の特徴事項と組み合わせることができる。
【００５７】
「１つの」、「ある」または「この」なる単語は、特に否定しない限り「１つ以上」を意味する。
【図１】
2009541864.tif 000003
【図２】
2009541864.tif 000004
【国際調査報告】
2009541864.tif 000005