JP2016529768A - 医療データへのアクセスを管理するシステム - Google Patents

Abstract

本願は、医療データへのアクセスを管理するシステムに関する。システムは、医療データへのアクセスをデータプロバイダに要求するためのデータ要求情報を表示する第１モジュールと、第１モジュールからデータ要求情報を入手し、その入手したデータ要求情報に基づき医療データへのアクセスをデータプロバイダに要求する第２モジュールとを有する。第１モジュールは、データ要求情報を、例えばＱＲコード（登録商標）として表示することによって、供給することができる。データ要求情報は、データプロバイダへリンクするＵＲＬを有してよい。データプロバイダは、医療データを局所的に記憶することができ、あるいは、例えばＰＨＲサーバのような遠隔のソースから医療データを読み出すことができる。データアクセス要求に応答して、データプロバイダは、医療データが対応する患者にユーザ認証を要求し、成功した認証に応答してのみ医療データを第２モジュールへ提供してよい。

Description

本発明は、医療データへのアクセスを管理するシステムに関し、特に、患者と医療関係機関との間で医療データを共有することに関する。

ヘルスケア環境では、医師又は他の医療関係機関と医療データを共有可能であることが患者にとって望ましい。例えば、医療データは、患者の以前の検査結果に関する情報を含むことができ、医療データを共有することによって、検査を繰り返す必要性は回避され得る。有効な医療データ管理システムは、医師が、以前の作業を繰り返すことではなく、患者と対話することにもっと時間を費やすことを可能にすることによって、ケアの品質を改善するとともに、ケアのコストを削減することができる。しかし、プライバシを確保するよう、医療データは安全且つセキュアな方法で共有されること、特には、患者は誰が自身の医療データにアクセスすることを許されるのかを制御可能であることが望ましい。

医療データを共有するための様々なシステムが知られており、電子健康記録（ＥＨＲ（ｓ）；Electronic Health Record(s)）、電子医療記録（ＥＭＲ（ｓ）；Electronic Medical Record(s)）、個人健康記録（ＰＨＲ（ｓ）；Personal Health Record(s)）、及び医療情報カードがある。医療情報カードは、例えば、内蔵のＵＳＢコネクタを通じてアクセスされ得るメモリモジュールにおいて、医療情報を記憶する。ＥＨＲ又はＥＭＲは、病院、総合医療ネットワーク（integrated delivery network）、診療所、又は医師のオフィスなどの施設によって生成されて保持されている医療記録情報の電子レポジトリである。ＰＨＲは、それが、医療施設とは対照的に、個々の患者によって保持されている医療記録情報の電子レポジトリであるという点で相違する。

ＰＨＲからのデータを共有するには、ユーザは多数のステップを完了しなければならない。通常、患者がＰＨＲからのデータを共有することを可能にするよう、ヘルスケア機関は、登録された患者がログインして、ＰＨＲとの健康情報の交換を可能にするＰＨＲを組み込んだオフラインのアプリケーションを作成することができる。アプリケーションは、ＰＨＲからの患者データにアクセスするために医師がログインするためのログインウィンドウを更に有することができる。医師は、アプリケーションにログインして、一意の患者ＩＤを用いて特定の患者を選択することができる。アプリケーションは、対応するＰＨＲ記録からデータを引き出して、それを医師に示す。

本発明の目的は、患者データにアクセスするためのシステムであって、上記の問題を実質的に軽減し又は解消するシステムを提供することである。

本発明の態様に従って、患者に対応する医療データへのアクセスを管理するシステムが提供される。当該システムは、前記医療データへのアクセスを提供するよう構成されるデータプロバイダと、前記データプロバイダに前記医療データへのアクセスを要求するためのデータ要求情報を供給するよう構成される第１モジュールと、前記第１モジュールから前記データ要求情報を入手し、該入手したデータ要求情報に基づき前記データプロバイダに前記医療データへのアクセスを要求するよう構成される第２モジュールとを有する。前記第１モジュール及び前記第２モジュールは、物理的に別々のデバイスとして、あるいは、同じ物理デバイスによって実行されるソフトウェアアプリケーションとして、具現され得る。

この配置は、従来のＰＨＲアプリケーションによって必要とされる時間がかかる登録及び設定の工程を経る必要なしに容易に医療データが共有され得るという利点を提供する。データを共有するには、ユーザは、例えば、医師がスマートフォン又はタブレットコンピュータを用いてスキャンすることができるクイック・レスポンス（ＱＲ；Quick-Response）コードとしてデータ要求を表示することによって、必要なデータ要求情報を医師に与えさえすればよい。データ要求情報の使用は、医療データがどこでも記録され得るという利点を更に有する。これは、システムが、例えばＰＨＲ、ＥＨＲ及びＥＭＲなどの既存の記録システムと容易に相互作用することができることを意味する。

データ要求情報は、例えば、ユニバーサル・リソース・ロケータ（ＵＲＬ；Universal Resource Locator）の形で、直接リンクを有することができる。代替的に、いくつかの実施形態では、データ要求情報は、医療データに割り当てられた一意の識別子であることができる。例えば、異なる識別子は、異なる患者ごとの医療データへ割り当てられ得、異なる識別子は、同じ患者の医療データの予め定義されたサブセットへ割り当てられ得る。夫々の識別子は、データベースにおいて記憶され、対応する医療データの知られている場所を特定する情報と相互参照され得る。前記第２モジュールは、医療データを前記データプロバイダに要求するために、前記第１モジュールから識別子を入手し、データベースにクエリを行って、対応する医療データの前記知られている場所を特定する情報を読み出すことができる。データベースは、前記第２モジュールにおいて局所的に記憶されてよく、あるいは、遠隔からアクセスされてよい。更なる代替案として、いくつかの実施形態では、前記第２モジュールは、一意の識別子を前記データプロバイダへ送信することによって医療データを要求することができ、前記データプロバイダは、上述されたようにデータベースにクエリを行うことによって、医療データを読み出すことができる。代替的に、一の識別子の代わりに、データ要求情報は、他の方法で患者の医療データのサブセットを識別してよい。例えば、データ要求情報は、患者のごく近い親戚が罹患した病気に関する情報に関する家族既往歴データの要求、又は最近（例えば、６ヶ月前から今日までの期間）の患者の医療データを含む最近の患者データの要求といった、特定のサブセットを要求するクエリを含んでよい。

いくつかの実施形態では、前記第１モジュールは、データ要求情報に１つ以上のアクセスパラメータを含めるよう構成され、該アクセスパラメータは、如何にして医療データが前記第２モジュールと共有されるのかに関するパラメータを含み、前記第２モジュールは、医療データを要求する場合にアクセスパラメータを前記データプロバイダへ送信するよう構成され、前記データプロバイダは、アクセスパラメータに基づき前記第２モジュールによる医療データへのアクセスを制御するよう構成される。前記１つ以上のアクセスパラメータは、前記第２モジュールが医療データにアクセスすることを許される期間を定義する期間パラメータ、及び／又は医療データに含まれる複数のデータ要素のうちのどのデータ要素が前記第２モジュールによってアクセスされ得るのかを特定するデータ要素パラメータを含むことができる。

アクセスパラメータは、前記第２モジュールが医療データにアクセスすることを許可される様態を制御するために使用され得る。例えば、ユーザは、医療データのある特定のデータ要素のみが共有されるようにアクセス制限を設定することができる。この機能は、データが共有されることに対する詳細な制御をユーザに与える。

いくつかの実施形態では、前記データ要求情報は、前記データプロバイダへリンクするユニフォーム・リソース・ロケータ（ＵＲＬ）を含み、前記第２モジュールは、前記ＵＲＬへナビゲートすることによって医療データを要求するよう構成される。この配置は、前記第２モジュールを含むデバイスが、何らかのウェブブラウザを用いてウェブベースのアプリケーションを通じて医療データにアクセスすることを可能にすることができる。ウェブベースのアプリケーションの使用は、如何なる特定のソフトウェアもデバイスにインストールする必要なしに、種々のタイプの健康記録システムからの医療データがアクセスされることを可能にすることができる。

いくつかの実施形態では、前記第１モジュールは、例えばクイック・レスポンス（ＱＲ）コードとして、前記データ要求情報を表示するよう構成される。このアプローチは、データ要求情報が、捕捉された画像を処理してデータ要求情報を検出する（例えば、ＱＲコード（登録商標）として表示される場合には、ＱＲ読み取りアプリケーションを用いてデータ要求情報を検出し復号する）能力を備えた、カメラを含むあらゆるデバイスによって入手されることを可能にする。

いくつかの実施形態では、前記データプロバイダは、要求されている医療データが対応する患者に認証を要求することによって、前記医療データにアクセスするための前記第２モジュールからの要求に応答するよう構成され、認証の成功に応答して前記要求されている医療データへのアクセスを前記第２モジュールへ与えるよう構成される。認証の使用は、前記第１モジュールを含むデバイスが紛失又は盗難される場合に、第三者は、必要な認証情報、例えば、ユーザ名及びパスワードがなければ医療データにアクセスすることができないので、医療データの安全性が脅かされないことを意味する。いくつかの実施形態では、前記データプロバイダは、認証要求を前記第１モジュールへ送信し、認証情報を前記第１モジュールから受信し、該受信された認証情報を患者についての既知の認証情報と比較して認証が成功したかどうかを判定することによって、認証を要求するよう構成される。これは、前記第２モジュールが認証に関与しないので、認証情報が前記第２モジュールによってインターセプトされる如何なる危険性も回避する。

いくつかの実施形態では、前記データ要求情報は、前記第１モジュール又は前記第２モジュールを特定する認証デバイス情報を含み、前記データプロバイダは、前記認証デバイス情報によって特定される前記第１モジュール又は前記第２モジュールに認証を要求するよう構成される。これは、前記第１モジュールが認証情報を提供することができない場合、例えば、前記第１モジュールが、認証情報が入力され得る如何なるユーザインタフェースも有さない場合でさえ実行され得る認証を可能にすることができる。

いくつかの実施形態では、前記第２モジュールから前記医療データへのアクセスのための要求を受信した後、前記データプロバイダは、前記データ要求情報が前のデータ要求において既に使用されているかどうかを判定し、前記データ要求情報が前のデータ要求において使用されていないと決定される場合にのみ前記要求されている医療データへのアクセスを前記第２モジュールへ与えるよう構成される。

いくつかの実施形態では、前記第１モジュールは、保護されたトークンを入手し、該保護されたトークンを前記データ要求情報に含めるよう構成され、前記保護されたトークンは、暗号化キーを用いて保護されているトークンを有し、前記データプロバイダは、前記第２モジュールから前記保護されたトークンを受信し、予想される暗号化キーを用いて前記保護されたトークンを処理し、前記予想される暗号化キーを用いて前記トークンの入手に成功するならば、前記予想される暗号化キーが以前に使用されなかった場合に前記データ要求情報が前のデータ要求において使用されていないと決定するよう構成される。

いくつかの実施形態では、前記第１モジュールは、トークンを入手して、該トークンを前記暗号化キーにより保護することによって、前記保護されたトークンを得るよう構成される。例えば、前記第１モジュールは、暗号化キーを用いて暗号化を適用することによって、トークンを保護することができる。他の実施形態では、前記第１モジュールは、複数の保護されたトークンから前記保護されたトークンを選択するよう構成される。例えば、前記第１モジュールは、予め決定されている保護されたトークン、例えば、暗号化キーを用いて既に暗号化されている暗号化されたトークン、のリストをインストールされ得る。暗号化が上記の例では記載されているが、他の実施形態では、例えば認証などの他のタイプの暗号化による保護が、上記の暗号化に代えて、又はそれに加えて、適用されてよい。

いくつかの実施形態では、前記データプロバイダは、現在のデータ要求より前に最も最近に受信されたデータ要求において使用された暗号化キーである前の暗号化キーに暗号化アルゴリズムを適用することによって、前記予想される暗号化キーを得るよう構成される。いくつかの実施形態では、暗号化アルゴリズムは、前記データプロバイダ及び前記第１モジュールの両方に知られているハッシュ関数であり、それにより、前記データプロバイダ及び前記第１モジュールはいずれも、前の暗号化キーから同じ暗号化キーを得ることができる。

いくつかの実施形態では、前記データプロバイダは、１つ以上の遠隔の医療記録サーバから医療データを読み出し、該読み出された医療データを前記第２モジュールへ送信することによって、医療データへのアクセスを与えるよう構成される。これを行うことによって、当該システムは、既存の医療記録システムと容易に一体化され得る。例えば、１つ以上の遠隔の医療記録サーバは、１つ以上の個人健康記録（ＰＨＲ）サーバ、及び／又は１つ以上の電子健康記録（ＥＨＲ）サーバ、及び／又は１つ以上の電子医療記録サーバを含むことができる。

いくつかの実施形態では、前記データプロバイダ及び前記第１モジュール又は前記第２モジュールのような当該システムのコンポーネントは、単一の物理デバイスにおいて具現され得る。他の実施形態では、当該システムの様々なコンポーネントは、２つ以上のデバイスの間で分布することができる。

本発明の他の態様に従って、上記のシステムにおいて第１モジュールとして使用される装置が提供される。当該装置は、前記データプロバイダに医療データへのアクセスを要求するためのデータ要求情報を生成するよう構成されるデータ要求情報生成部と、前記生成されたデータ要求情報を前記第２モジュールへ供給するよう構成されるデータ要求情報提供モジュールとを有する。

本発明の他の態様に従って、前記第１モジュールの制御方法が提供される。当該方法は、前記データプロバイダに医療データへのアクセスを要求するためのデータ要求情報を生成するステップと、該データ要求情報を前記第２モジュールへ供給するステップとを有する。

本発明の他の態様に従って、データプロバイダとして使用される装置が提供される。当該装置は、患者に対応する医療データを検索するよう構成されるコントローラと、認証を要求するよう構成される認証モジュールと、前記第１モジュール及び前記第２モジュールと通信するよう構成される通信モジュールとを有する。医療データへのアクセスを与えるよう前記第２モジュールから前記通信モジュールを通じて受信された要求に応答して、前記コントローラは、前記通信モジュールを通じて前記第１モジュール又は前記第２モジュールに認証を要求し、認証が成功したかどうかを判定するように前記認証モジュールを制御するよう構成され、成功した認証に応答して、前記コントローラは、前記要求されている医療データへのアクセスを前記通信モジュールを通じて前記第２モジュールへ与えるよう構成される。

本発明の他の態様に従って、医療データを提供する方法が提供される。当該方法は、前記医療データへのアクセスを与えるための要求を受けるステップと、前記医療データへのアクセスのための前記要求に応答して、第１モジュール又は第２モジュールに認証を要求するステップと、認証が成功したかどうかを判定するステップと、成功した認証に応答して、前記要求されている医療データへのアクセスを与えるステップとを有する。

本発明の他の態様に従って、上記のシステムにおいて第２モジュールとして使用される装置が提供される。当該装置は、前記第１モジュールからデータ要求情報を得るよう構成されるデータ要求情報検出部と、前記データプロバイダと通信する通信モジュールと、前記得られたデータ要求情報に基づき医療データへのアクセスを前記データプロバイダに要求するように前記通信モジュールを制御するよう構成されるコントローラとを有する。

本発明の他の態様に従って、第２モジュールで医療データへのアクセスを要求する方法が提供される。当該方法は、第１モジュールから、データプロバイダに医療データへのアクセスを要求するための情報を含むデータ要求情報を入手するステップと、該入手されたデータ要求情報に基づき医療データへのアクセスを前記データプロバイダに要求するステップとを有する。

本発明の他の態様に従って、コンピュータプログラムを記憶するよう構成されるコンピュータ可読記憶媒体が更に提供される。前記コンピュータプログラムは、デバイスによって実行される場合に、該デバイスに、ここで記載される方法のいずれかを実行させる。

本発明のそれら及び他の態様は、以降で記載される実施形態を参照して説明され、それらの実施形態から明らかになるであろう。

本発明の実施形態に従って、患者に対応する医療データへのアクセスを管理するシステムを概略的に示す。 本発明の実施形態に従って、図１のシステムにおいて第１モジュールとして使用される装置を概略的に示す。 本発明の実施形態に従って、図１のシステムにおいて第２モジュールとして使用される装置を概略的に示す。 本発明の実施形態に従って、認証を用いて医療データへのアクセスを管理するシステムを概略的に示す。 本発明の実施形態に従って、図４のシステムにおいてデータプロバイダとして使用される装置を概略的に示す。 図４のシステムの動作を説明するフロー図を示す。 本発明の実施形態に従って、複数の個人健康記録（ＰＨＲ）からの医療データへのアクセスを管理するシステムを概略的に示す。 本発明の実施形態に従って、データ要求情報を生成し供給する方法を説明するフロー図を示す。 本発明の実施形態に従って、医療データへのアクセスを管理する方法を説明するフロー図を示す。 本発明の実施形態に従って、認証を実行すべきデバイスを選択する方法を説明するフロー図を示す。

本発明の実施形態は、これより、単なる一例として、添付の図面を参照して記載される。

図１は、本発明の実施形態に従って、患者に対応する医療データへのアクセスを管理するシステムを概略的に示す。システムは、医師が患者の医療データにアクセスすることを許可するために使用されてよく、ヘルスケア支援システムと呼ばれ得る。

システム１００は、第１デバイス１１０、第２デバイス１２０、及びデータプロバイダ１３０を有する。データプロバイダ１３０は、医療データを第２デバイス１２０へ供給するよう構成される。第１デバイス１１０は、医療データを共有するために使用されてよく、以降‘患者用デバイス’と呼ばれる。第２デバイス１２０は、患者によって共有されている医療データを見るために使用されてよく、以降‘医師用デバイス’と呼ばれる。医療データは局所的に記憶されてよく、あるいは、データプロバイダ１３０によって遠隔の位置からアクセスされ得る。例えば、データプロバイダ１３０は、インターネットを介して１つ以上のＰＨＲから医療データを読み出すことができる。以下で更に詳細に記載されるいくつかの実施形態では、データプロバイダ１３０は、医療データへのアクセスを与える前に、患者認証を必要としてよい。

患者用デバイス１１０は、データプロバイダ１３０を通じて医療データにアクセスする際に使用されるデータ要求情報を表示するよう構成される。本実施形態では、データ要求情報は、データプロバイダ１３０へリンクするユニフォーム・リソース・ロケータ（ＵＲＬ）を有する。加えて、データ要求情報は、医療データをデータプロバイダ１３０に要求するためのデータ要求トークンを更に有してよい。データ要求トークンは、データプロバイダ１３０へ渡されるべきＵＲＬパラメータとして与えられる。

患者用デバイス１１０は、データ要求情報をスクリーン上に表示することができ、例えば、スマートフォン、タブレット、汎用コンピュータ又はあらゆる他の適切な装置であることもできる。本原理では、患者用デバイス１１０は、スマートフォンであり、クイック・レスポンス（ＱＲ）コード１４０としてデータ要求情報を表示するよう構成されるが、他の実施形態では、データ要求情報は、異なるフォーマットで、例えば、バーコードとして又はプレーンテキストとして、表示され得る。

他の実施形態では、患者用デバイス１１０は、必ずしもスクリーンでなくてもよい如何なる表面上にも、データ要求情報を表示することができる。例えば、いくつかの実施形態では、患者用デバイス１１０は、ブレスレットのような装着可能なアイテムであることができ、データ要求情報は表面上に刻印又は印刷される。更に、他の実施形態では、データ要求情報は表示されなくてもよく、例えば無線周波数識別（ＲＦＩＤ；Radio-Frequency Identification）又は他のタイプの近距離通信（ＮＦＣ；Near-Field Communication）方法などの他の適切な方法を用いて患者用デバイスから医師用デバイスへ転送されてよい。

医師用デバイス１２０は、表示されているデータ要求情報を検出するよう構成される。医師用デバイス１２０は、検出されたデータ要求情報に基づきデータプロバイダ１３０を通じて医療データにアクセスするよう更に構成される。本実施形態では、データ要求情報はＱＲコード（登録商標）１４０として表示されるので、医師用デバイス１２０は、患者用デバイス１１０の画像を捕捉し、その捕捉された画像を処理してＱＲコード（登録商標）１４０を検出し、ＱＲコード（登録商標）１４０を復号してデータ要求情報を得ることによって、データ要求情報を入手するよう構成される。他の実施形態では、データ要求情報は、バーコードとして表示され、医師用デバイス１２０は、バーコード読み取り器を用いて、表示されているデータ要求情報を検出するよう構成される。本実施形態では、医師用デバイス１２０はスマートフォンであるが、他の実施形態では、医師用デバイス１２０は、タブレット、汎用コンピュータ又はあらゆる他の適切な装置であることもできる。

上述されたように、本実施形態では、データ要求情報は、データプロバイダ１３０へリンクするユニフォーム・リソース・ロケータ（ＵＲＬ）を有するが、他の実施形態では、ＵＲＬ以外の異なるフォーマットがデータプロバイダ１３０へリンクするために使用されてよい。医療データへアクセスするよう、第２デバイス１２０は、ウェブブラウザアプリケーションを通じてＵＲＬへナビゲートするよう構成され、その結果、ウェブブラウザアプリケーションは、ＵＲＬにおいて特定されるリソースをデータプロバイダ１３０に要求する。ＵＲＬは、例えば、医療データが要求されている患者に対応するディレクトリを指定することによって、要求されている医療データを特定するパスを含んでよい。代替的に、要求されている医療データは、他の様態において、例えば、データプロバイダ１３０において実行されるソフトウェアへ渡されるＵＲＬに含まれるクエリ列によって、特定され得る。

医師用デバイス１２０及びデータプロバイダ１３０は、例えばＢｌｕｅｔｏｏｔｈ（登録商標）接続又は無線ローカルエリアネットワーク（ＷＬＡＮ；Wireless Local Area Network）接続などの、如何なる有線又は無線接続を介しても通信するよう構成され得る。データプロバイダ１３０は、患者用デバイス１１０及び医師用デバイス１２０とは別個のスタンドアローンの装置として具現され得る。代替的に、いくつかの実施形態では、データプロバイダ１３０は、患者用デバイス１１０又は医師用デバイス１２０と同じ物理装置において具現されてよい。例えば、患者用デバイス１１０がスマートフォンであるとき、データプロバイダ１３０は、患者用デバイス１１０においてインストールされているソフトウェアアプリケーションとして具現されてよく、医師用デバイス１２０は、データプロバイダ１３０を通じて医療データにアクセスするよう患者用デバイス１１０と通信することができる。

データ要求情報を表示することによって、患者用デバイス１１０は、ユーザ、例えば、患者又は患者の介護人が、患者の記憶されている医療データへのアクセスを制御することを可能にする。例えば、医師が記憶されている医療データにアクセスすることを許可するよう、患者は、表示されているデータ要求情報を医師に示すことができる。医師は、医師用デバイス１２０を用いて、表示されているデータ要求情報をスキャンすることができる。次いで、医師用デバイス１２０は、医療データにアクセスするために、スキャンされたデータ要求情報を使用する。システム１００は、医師用デバイス１２０が、表示されているデータ要求情報を検出するために患者用デバイス１１０の視線方向の視認性なしでは医療データにアクセスすることができないために、患者の医療データへのアクセスを安全に管理することができる。

図２は、本発明の実施形態に従って、図１のシステムにおいて患者用デバイスとして使用される装置を概略的に示す。装置２１０は、ユーザインタフェース２１１、アクセスパラメータ設定モジュール２１２、データ要求情報生成部２１３、及びディスプレイ２１４を有する。

ユーザインタフェース２１１は、如何にして医療データが第２デバイスと共有されるべきかに関する１つ以上のアクセスパラメータを選択するユーザ入力を受けることができる。これは、医療データが第２デバイスと共有される範囲をユーザが定義することを可能にする。ユーザ入力によって選択され得るアクセスパラメータの例には、第２デバイスが医療データにアクセスすることを許される期間、及びデータ要素制限があるが、これらに限られない。具体的に、医療データは、複数のデータを含むことができ、ユーザは、データ要素のうちのどれが第２デバイスによってアクセスされ得るのかを制御するようデータ要素制限を設定することができる。

アクセスパラメータ設定モジュール２１２は、定義されたアクセスパラメータをデータ要求情報生成部２１３へ送信するよう構成される。データ要求情報生成部２１３は、生成されるデータ要求情報にアクセスパラメータを含める。アクセスパラメータを含む生成されたデータ要求情報は、次いで、ディスプレイ２１４において表示される。

本実施形態では、データ要求情報は、データプロバイダへリンクするＵＲＬを含む。図１を参照して上述されたように、ＵＲＬの形式は、どの医療データが第２デバイスによって要求されているのかをデータプロバイダ１３０に示す。また、本実施形態では、装置２１０は、データ要求情報をＱＲコード（登録商標）に変換するソフトウェアを含む。如何なる適切なＱＲコード（登録商標）発生器もこの目的のために使用され得る。データ要求情報は、その場合に、ＱＲコード（登録商標）としてディスプレイ２１４において表示される。

本実施形態では、装置２１０は、データ要求情報を第２デバイスへ供給するためのディスプレイを有するが、他の実施形態では、データ要求情報は、異なる方法、例えばＮＦＣを用いて、供給されてよい。一般論として、患者用デバイスは、如何なる適切なデータ要求情報提供モジュールも有することができ、例えば、図２に示されるディスプレイ、ＲＦＩＤ送信器、又はネットワークインタフェースモジュールであってよい。本発明は、一例として記載されているそれらのタイプのデータ要求情報提供モジュールに制限されない。

図３は、本発明の実施形態に従って、図１のシステムにおいて医師用デバイスとして使用される装置を概略的に示す。装置３２０は、コントローラ３２１、データ要求情報検出部３２２、通信モジュール３２３、及びディスプレイ３２４を有する。装置３２０は、例えばネットワーク接続を介して、データプロバイダと通信するために、通信モジュール３２３を使用することができる。本実施形態では、通信モジュール３２３はＷＬＡＮモジュールであるが、他の実施形態では、異なる通信プロトコルが使用されてよい。

コントローラ３２１は、患者用デバイスにおいて表示されているデータ要求情報を検出するようデータ要求情報検出部３２２を制御する。本実施形態では、データ要求情報は、ＱＲコード（登録商標）の形で表示され、データ要求情報検出部３２２は、患者用デバイスの画像を捕捉するカメラを有する。画像捕捉プロセスは、従来の方法においてユーザによって制御され得る。画像が捕捉されると、装置は、画像を処理してＱＲコード（登録商標）を検出及び復号し、データ要求情報を入手する。この目的のために、従来のＱＲコード（登録商標）読み取りアプリケーションが装置３２０にインストールされてよく、あるいは、専用ハードウェアのＱＲコード（登録商標）プロセッサが設けられてよい。

本実施形態では、データ要求情報検出部はカメラであるが、データ要求情報を第２デバイスへ供給するために患者用デバイスによって使用される方法に従って、他の実施形態では、異なるタイプのデータ要求情報検出部が使用されてよいことは明らかである。例えば、データ要求情報検出部は、ＲＦＩＤ信号としてデータ要求情報を受信するよう構成されるＲＦＩＤ受信器、又はネットワークを介してデータ要求情報を受信するよう構成されるネットワークインタフェースモジュールであることができる。本発明は、一例として記載されているそれらのタイプのデータ要求情報検出部に制限されない。

データ要求情報が得られると、コントローラ３２１は、通信モジュール３２３を通じて、データ要求情報に基づきデータプロバイダに医療データを要求する。要求されている医療データは、次いで、如何なる必要な認証プロシージャ及び／又はアクセス制限も満足されているとして、データプロバイダから通信モジュール３２３を通じて受信される。コントローラ３２１は、受信された医療データを表示するようディスプレイ３２４を制御する。本実施形態では、医療データは、データ要求と同じ通信リンク上で送信されるが、他の実施形態では、医師用デバイス３２０は、異なる通信リンク上で医療データを受信することができる。

例えば図３に示されているような装置は、単に、患者用デバイスにおいて表示されているデータ要求情報をスキャンすることによって、患者の医療データに素早く且つ容易にアクセスするために使用され得る。

図４は、本発明の実施形態に従って、認証を用いて医療データへのアクセスを管理するシステムを概略的に示す。システム４００は、患者用デバイス４１０、医師用デバイス４２０、及びデータプロバイダ４３０を有する。システム４００は、図１のシステムと類似しているが、データプロバイダが、要求されている医療データを医師用デバイス４２０に供給する前に患者に認証を要求するよう構成されている特徴が加えられている。

上記のアプローチのいずれかを用いて、患者用デバイス４１０は、データ要求情報を表示することができ、医師用デバイス４２０は、患者用デバイス４１０によって表示されているデータ要求情報を検出し、データプロバイダ４３０に医療データを要求することができる。本実施形態のデータプロバイダ４３０が医師用デバイス４２０からの医療データの要求を受け取る場合に、データプロバイダ４３０は、要求されている医療データが対応する患者に認証を要求することによって応答する。本実施形態では、図４に示されるように、データプロバイダ４３０は、認証要求を患者用デバイス４１０へ送信することによって、医師用デバイス４２０からのデータアクセス要求に応答する。患者用デバイス４１０は、認証要求を受け取り、ユーザに認証情報、例えば、ユーザ識別子（ＩＤ）及びパスワード（ＰＷＤ）を入力するよう促す。認証情報が入力された後、患者用デバイス４１０は、認証情報をデータプロバイダ４３０へ送信する。認証方法は知られており、詳細な説明は、簡潔さを保つために省略される。なお、手短に、データプロバイダ４３０は、受信された認証情報を患者についての既知の認証情報と比較し、受信された認証情報が既知の認証情報と一致する場合に認証が成功したと決定するよう構成される。データプロバイダ４３０は、要求されている医療データを医師用デバイス４２０に提供することによって、成功した認証に応答するよう更に構成される。

他の実施形態では、異なる認証方法が使用され得る。例えば、認証は、患者用デバイス４１０において入力された認証情報を既知の認証情報と比較することによって、データプロバイダ４３０ではなく患者用デバイス４１０で実行され得る。これを行うことによって、認証情報をデータプロバイダ４３０へ送信する必要はない。代わりに、患者用デバイス４１０は、認証の結果をデータプロバイダ４３０へ送信しさえすればよい。このアプローチは、送信がインターセプトされる場合に認証情報が脅かされる危険性がないので、より安全であり得る。

本実施形態では、認証を与える権限を与えられているユーザは、要求されている医療データが対応する患者であるが、他の実施形態では、患者に代えて、又は患者に加えて、他のユーザが、データ要求を許可することを認められてよい。一例として、ブレークグラスプロシージャが本発明の実施形態において実施され得る。患者がデータ要求を許可することができない場合に、例えば、患者が負傷又は疾病のために能力を奪われている場合に、有資格のヘルスケア提供者は、医療データが依然としてアクセスされ得ることを確かにするよう通常の権限付与プロシージャに優先するために使用され得る。ブレークグラスプロシージャは、緊急事態において使用される最重要のデータを含む予め定義された医療データのサブセットへのアクセスのみを提供してよい。緊急アカウントを介したアクセスは、ブレークグラスプロシージャが正真正銘の緊急事態においてのみ使用されることを確かにするよう監査プロシージャによって制限され且つ監視されるべきである。

本実施形態では、データプロバイダ４３０は、認証要求を患者用デバイス４１０へ送信するが、本発明はこのアプローチに制限されない。例えば、他の実施形態では、認証要求は、代わりに医師用デバイス４２０へ送信され得る。医師用デバイス４２０で認証を実行することは、患者用デバイス４１０が認証を実行することができない場合、例えば、患者用デバイス４１０が受信又は送信機能を備えず、且つ／あるいは、認証情報を入力するためのユーザインタフェースを有さない場合に、適切であり得る。

いくつかの実施形態では、患者用デバイス４１０は、患者用デバイス４１０又は医師用デバイス４２０を特定する認証デバイス情報を含むデータ要求情報を表示するよう構成され得る。医師用デバイス４２０は、その場合に、データプロバイダ４３０へ送信されるデータ要求に認証デバイス情報を含め、データプロバイダ４３０は、認証デバイス情報によって特定されるデバイスに認証を要求する。このアプローチは、患者用デバイスが、認証が患者用デバイスで又は医師用デバイスで実行されるべきかどうかを指定することを可能にする。従って、患者用デバイスが認証に関与する能力を有さない場合は、患者用デバイスは、認証が代わりに医師用デバイスによって実行されるべきことをデータプロバイダへ知らせるために、認証デバイス情報を使用することができる。

図５は、本発明の実施形態に従って、図４のシステムにおいてデータプロバイダとして使用される装置を概略的に示す。図５に示されるように、装置５３０は、コントローラ５３１、認証モジュール５３２、通信モジュール５３３、データアクセス管理モジュール５３４、及び権限付与モジュール５３５を有する。

コントローラ５３１は、通信モジュール５３３を通じて医療データの要求を受信するよう構成される。本実施形態では、要求は、データ要求を許可するトークンを含み、権限付与モジュール５３５は、データ要求を認めるべきかどうかを判断するために、受信されたトークンをバリデートするよう構成される。

権限付与モジュール５３５がトークンをバリデートすることに成功したことに応答して、コントローラ５３１は、要求されているデータを供給する前に認証を実行するよう認証モジュール５３２を制御する。認証モジュール５３２は、図４を参照して上述されたように、通信モジュール５３３を通じて患者用デバイスへ認証要求を送信する。認証モジュール５３２は、通信モジュール５３３を通じて認証情報を受信し、受信された認証情報を、許可されたユーザ（本実施形態では、要求されているデータが対応する患者である。）の既知の認証情報と比較し、一致する場合に認証が成功したと決定する。いくつかの実施形態では、認証モジュール５３２は、例えば、ユーザが医療従事者であることを確かめるためにセキュリティ・アサーション・マークアップ言語（ＳＡＭＬ；Security Assertion Markup Language）トークン又は公衆キーインフラストラクチャ（ＰＫＩ；Public-Key Infrastructure）証明書を用いて、要求元デバイスのユーザを認証するよう更に構成される。

成功した認証に応答して、コントローラ５３１は、適切なデータソース、例えばＰＨＲから医療データを入手するためにデータアクセス管理モジュール５３４を用いることによって、要求されている医療データを読み出し、医療データを医師用デバイスへ通信モジュール５３３を通じて送信する。データアクセス管理モジュール５３４は、様々なＰＨＲ、ＥＨＲ及びＥＭＲを含む多種多様な医療データソースとともに動作するよう構成され得る。

本実施形態では、データ要求、認証要求、認証情報及び医療データは同じ通信リンクを介して送信されるが、他の実施形態では、通信モジュール５３３は、２つ以上の別々の通信リンクを利用するよう構成され得る。例えば、通信モジュール５３３は、認証を実行するようＢｌｕｅｔｏｏｔｈ（登録商標）接続を介して患者用デバイスと通信することができ、医療データは医師用デバイスへＷＬＡＮ接続を介して送信することができる。

図６は、図４のシステムの動作を説明するフロー図を示す。フロー図は、患者用デバイス４１０、医師用デバイス４２０、及びデータプロバイダ４３０で実行されるステップを表す。

最初に、ステップＳ１０で、患者用デバイス４１０は、データ要求情報を生成する。実施形態に応じて、データ要求情報は、医師用デバイス４２０がその後のデータ要求においてデータ要求情報を再利用することを防ぐよう、例えばアクセスパラメータ、認証デバイス情報及び／又は一時使用コードのような他の情報を含んでよい。本実施形態では、データ要求情報はＵＲＬ及びＵＲＬパラメータとしてのデータ要求トークンを有するが、他の実施形態では、異なるフォーマットが使用されてよい。

次いで、ステップＳ１１で、生成されたデータ要求情報は、患者用デバイス４１０において表示される。本実施形態では、データ要求情報はＱＲコード（登録商標）として表示され、ステップＳ１１は、生成されたＵＲＬをＱＲコード（登録商標）に変換するステップを含む。

次に、ステップＳ１２で、医師用デバイス４２０は、表示されているデータ要求情報を検出する。本実施形態では、このステップは、患者用デバイス４１０の画像を捕捉し、画像を処理してＱＲコード（登録商標）を検出及び復号することを伴うが、上述されたように、データ要求情報を検出する他の方法が他の実施形態では使用され得る。次いで、ステップＳ１３で、医師用デバイス４２０は、ＵＲＬへナビゲートし、データ要求情報に含まれるデータ要求トークンを送信することによって、医療データへのアクセスを要求するようデータアクセス要求をデータプロバイダ４３０へ送信する。

次いで、ステップＳ１４で、データ要求トークンを含むデータアクセス要求は、データプロバイダ４３０によって受信される。データ要求情報が、例えば、アクセスパラメータ、認証デバイス情報及び／又は一時使用（single-use）コードのような他のパラメータを含むＵＲＬである場合に、それらの他のパラメータはデータアクセス要求において受信され、従って、データプロバイダ４３０が利用可能である。

次に、ステップＳ１５で、データプロバイダ４３０は、患者用デバイス４１０に認証を要求する。患者用デバイス４１０は、ステップＳ１６で認証要求を受信する。ステップＳ１７で、患者用デバイス４１０は、例えばユーザＩＤ及びパスワードのような認証情報を入手する。認証情報は、患者用デバイス４１０において記憶されていても、あるいは、ユーザにユーザインタフェースを通じて認証情報を入力するよう促すことによって入手されてもよい。次いで、認証情報は、ステップＳ１８で患者用デバイス４１０によって送信され、ステップＳ１９でデータプロバイダ４３０によって受信される。ステップＳ２０で、データプロバイダ４３０は、受信された認証情報を、許可されたユーザ（本実施形態では、要求されている医療データが対応する患者である。）の既知の認証情報と比較することによって、認証が成功したかどうかを確認する。

成功した認証に応答して、要求されている医療データは、ステップＳ２１で読み出され、ステップＳ２２で医師用デバイス４２０へ送信される。医師用デバイス４２０は、ステップＳ２３で医療データを受信し表示する。

図６の方法は、医師用デバイス４２０によってスキャンされ得るデータ要求情報の使用により、患者と医師との間の医療データの迅速且つ容易な共有を助けることができる。同時に、認証メカニズムの使用は、医療データが患者からの明示的な許可なしではアクセスされ得ないことを確かにする。これは、患者用デバイス４１０が紛失又は盗難される場合において更なる安全性を提供することができる。

本実施形態では、データプロバイダ４３０は、ステップＳ１５で患者用デバイス４１０に認証を要求するが、他の実施形態では、データプロバイダ４３０は、ステップＳ１５で医師用デバイス４２０に認証を要求する。この実施形態では、認証ステップＳ１６、Ｓ１７及びＳ１８は医師用デバイス４２０で実行されることが理解されるであろう。データ要求情報は、認証が実行されるべきデバイスを特定し、データ要求においてデータプロバイダ４３０へ渡されるデバイス認証情報を含むことができる。更に、上述されたように、認証が成功したかどうかを判定するステップ（Ｓ２０）は、患者用デバイス４１０又は医師用デバイス４２０で実行され得る。これは、ステップＳ１８及びＳ１９において、認証結果が認証情報の代わりに送信及び受信されることを意味する。

図７は、本発明の実施形態に従って、複数の個人健康記録（ＰＨＲ）からの医療データへのアクセスを管理するシステムを概略的に示す。システム７００の多くの態様は、図１及び４に示されたシステムの対応する態様と類似し、同様の部分の詳細な説明は、簡潔さを保つためにここでは省略される。

本実施形態のシステム７００は、患者用デバイス７１０、医師用デバイス７２０、データプロバイダ７３０、並びに第１、第２及び第３ＰＨＲ７５１、７５２、７５３を有する。特定の患者についての医療データの要求に応答して、データプロバイダ７３０は、特定の患者のデータを第１、第２及び第３ＰＨＲ７５１、７５２、７５３から読み出すよう構成される。いくつかの実施形態では、患者の医療データは、同じ患者識別子の下でＰＨＲの夫々１つにおいて記憶されてよい。他の実施形態では、ＰＨＲシステム７５１、７５２、７５３の異なる１つは、同じ患者について異なる患者識別子を使用してよい。かかる実施形態では、同じ患者の医療データにアクセスするよう、データプロバイダ７３０は、異なるＰＨＲ７５１、７５２、７５３が同じ患者について使用する異なる患者識別子の相互参照を記憶するよう構成され得る。代替的に、データプロバイダ７３０は、名前、誕生日、国籍、及び／又は住所を例えば含み得る患者識別情報を読み出し、読み出された識別情報に対応する患者の医療データを読み出すよう夫々のＰＨＲ７５１、７５２、７５３にクエリを行うことができる。

図７のような実施形態は、患者が、例えばＰＨＲ、ＥＭＲ及びＥＨＲのような多種多様な記録システムからの医療データを容易に共有することを可能にすることができる。データプロバイダ７３０は、システムからデータを読み出し、データをトランスペアレントな方法で医師用デバイス７２０へ提供することができる。データプロバイダ７３０を通じて医療データへリンクするデータ要求情報７４０を使用することによって、医師用デバイス７２０は、夫々の個別的な記録システム７５１、７５２、７５３にアクセスするために別個のソフトウェアをインストールされる必要がない。データ要求情報７４０は、データ検索が、医師用デバイス７２０よりむしろ、データプロバイダ７３０によって管理されること可能にする。

３つのＰＨＲが図７には表されているが、他の実施形態では、１つ以上のＰＨＲであればいくつでもデータプロバイダ７３０を通じてアクセスされてよい。ＰＨＲからのデータにアクセスすることに代えて、又はそれに加えて、データプロバイダ７３０は、１つ以上のＥＭＲ及び１つ以上のＥＨＲを含む他のタイプの医療記録システムにアクセスしてよい。

図８は、本発明の実施形態に従って、データ要求情報を生成及び供給する方法を説明するフロー図を示す。方法は、上記の実施形態のいずれかにおける患者用デバイスによって使用され得る。

ステップＳ２４で、患者用デバイスは、如何にして医療データが第２デバイスと共有されるのかを制御するよう１つ以上のアクセスパラメータを選択するユーザ入力を受ける。これは、ユーザが、例えば、指定される期間の間データを共有することを選択することによって、及び／又は医療データに含まれる複数のデータ要素の中から共有されるべき特定のデータ要素のみを選択することによって、データ共有プロセスをカスタマイズすることを可能にする。

本実施形態では、データ要求情報はＵＲＬを含み、アクセスパラメータは、ＵＲＬに付加される１つ以上のクエリ列の形でデータ要求情報に含まれ得る。このように、アクセスパラメータは、医師用デバイスがウェブブラウザアプリケーションにおいてＵＲＬをロードするデータ要求において、自動的にデータプロバイダへ渡される。明らかなように、アクセスパラメータのための他のフォーマットが他の実施形態では使用され得る。

次いで、ステップＳ２５で、患者用デバイスは、例えば、複数の所定のデータ要求トークンの中から１つを検索することによって、又は所定のアルゴリズムにより新たなトークンを生成することによって、データ要求トークンを入手する。

次に、ステップＳ２６で、患者用デバイスは、トークンを暗号化する暗号化キー（Ｋ）を入手する。本実施形態では、現在の暗号化キーは、所定のハッシュキーを、最も最近に生成されたデータ要求情報においてトークンを暗号化するときに使用された前の暗号化キーに適用することによって、入手される。一般論として、現在の暗号化キーはＮ番目の暗号化キー（Ｋ_Ｎ）と呼ばれてよく、前の暗号化キーは（Ｎ−１）番目の暗号化キー（Ｋ_Ｎ−１）と呼ばれてよい。

第２の、その後の暗号化キーがハッシュ関数の繰り返しの適用によって導出される当初の暗号化キー（Ｋ_１）は、患者用デバイスとデータプロバイダとの間で共有される秘密キーである。例えば、患者用デバイス及びデータプロバイダはいずれも、システムのセットアップの間に当初の暗号化キーを供給され得る。患者用デバイスが、例えばスマートフォン又はタブレットコンピュータのような汎用デバイスである実施形態では、当初の暗号化キーは、システムでの使用のために患者用デバイスを設定するよう患者用デバイスにおいてダウンロードされインストールされるアプリケーション（“ａｐｐ”）に含まれ得る。

本実施形態では、患者用デバイスは、オンデマンドで暗号化キーを生成するが、他の実施形態では、患者用デバイスは、前もって生成されて患者用デバイスにインストールされているＮ個の予め定義された暗号化キーにより再設定される。例えば、予め定義された暗号化キーは、システムでの使用のために患者用デバイスを設定するよう患者用デバイスにおいてダウンロードされインストールされるアプリケーション（“ａｐｐ”）に含まれ得る。予め定義された暗号化キーの使用は、患者用デバイスがハッシュ関数及び当初の暗号化キーを供給されなければならないことを回避する。

次いで、ステップＳ２７で、患者用デバイスは、ステップＳ２５で入手したトークンを、ステップＳ２６で入手した現在の暗号化キーを用いて暗号化する。

前の暗号化キーにハッシュ関数を適用して夫々の暗号化キーを生成することによって、データ要求情報の夫々のインスタンスに含まれるトークンは、異なるキーを用いて暗号化され得る。このアプローチは、以下で更に詳細に記載されるように、データプロバイダが、如何なる所与のデータ要求情報もデータを共有するために以前に使用されたことがあるかどうかを判定することを可能にする。

次に、ステップＳ２８で、データ要求情報が生成される。データ要求情報は、ステップＳ２４で入手されたアクセスパラメータ及びステップＳ２７で入手された暗号化されたトークンの両方を含む。次いで、ステップＳ２９で、データ要求情報は、例えば、データ要求情報を表示することによって、医師用デバイスへ供給される。

本実施形態では、現在の暗号化キーは、データ要求トークンを暗号化するためにのみ使用されるが、他の実施形態では、データ要求情報の他の要素も暗号化され得る（例えば、アクセスパラメータ）。データプロバイダへのリンク、例えばＵＲＬがデータ要求情報に含まれる場合に、ＵＲＬは、好適には、それが医師用デバイスによって理解され得るように暗号化されないままである。ＵＲＬをデータ要求情報において暗号化されないままとすることによって、医師用デバイスは、当初の暗号化キーを供給される必要がなく、それによって、医師用デバイスがデータ要求情報の暗号化された要素内の情報にアクセスしたり又はそれを変更したりすることができないので、安全性を改善する。なお、いくつかの実施形態では、医師用デバイスは、当初の暗号化キーを供給されてもよい。その場合に、データプロバイダへのリンクを含むデータ要求情報の全体は、患者用デバイスによって暗号化され得る。

また、他の実施形態では、記憶されているアクセスパラメータ情報は、ステップＳ２４で、ユーザにより定義されるアクセスパラメータを生成することに代えて、読み出され得る。例えば、デフォルトのアクセスパラメータは、患者用デバイスの設定の間に設定されて記憶され得る。

更に、いくつかの実施形態では、アクセスパラメータ情報は使用されなくてよく、従って、ステップ２４は省略され得る。また、いくつかの実施形態は、一時使用の暗号化様態を使用しなくてよく、その場合に、ステップＳ２６及びＳ２７は省略され得る。

他の実施形態では、データ要求情報はＱＲコード（登録商標）として表示され、患者用デバイスは、夫々のコードがデータ要求情報及び必要に応じて何らかのアクセスパラメータ情報を含む複数の所定のＱＲコード（登録商標）を記憶するよう構成される。この実施形態では、ステップＳ２６は省略され、ステップＳ２７でオンデマンドでデータ要求情報を生成することに代えて、デバイスは、以前に使用されたことがない所定のＱＲコード（登録商標）の中の１つを単純に選択することができる。例えば、夫々のコードは、それが使用されると、利用可能なコードのリストから削除されてよく、あるいは、利用不可能とフラグを付され得る。夫々の所定のＱＲコード（登録商標）は一度しか使用されないので、この実施形態は、毎回新しいコードを入手して、オンデマンドで新しいデータ要求情報を生成する必要なしに、一時使用コードが使用された場合と同じ効果を達成することができる。

本実施形態では、患者用デバイスは、医師用デバイスからデータ要求を受信する場合にデータ要求情報が既に使用されているかどうかをデータプロバイダが判定することを可能にするよう、毎回異なった暗号化キーを入手するが、他の実施形態では、代替のアプローチが使用されてよい。例えば、他の実施形態では、患者用デバイスは、データ要求情報の夫々のインスタンスにおいて一意のトークンを含めるよう構成されてよく、データプロバイダは、現在受信されているトークンが以前に使用されたことがあるかどうかを判定するよう、受信されているデータ要求内のトークンの記録を保持することができる。同じトークンが患者用デバイスによって２回使用されないことを確かにするよう、患者用デバイスは、所定のトークンのリストから夫々のトークンを入手し、使用されると夫々のトークンを削除するか、あるいは、夫々のトークンに別なふうにフラグを付してよい。代替的に、患者用デバイスは、生成されたトークンが既に使用されているかどうかを判定するために、以前に使用されたトークンの記録を保持しながら、所定のアルゴリズムによりオンデマンドで夫々のトークンを生成してよい。生成されたトークンが既に使用されている場合は、患者用デバイスは、未だ使用されていないトークンが見つけられるまで新しいトークンを生成し続けることができる。このように、患者用デバイスが、医療データへのアクセスの新たな要求を許可するよう新しいデータ要求情報を生成するたびに、一意のトークンが、データプロバイダによる検出のためにデータ要求情報に含まれ得ることが確かにされ得る。

図９は、本発明の実施形態に従って、医療データへのアクセスを管理する方法を説明するフロー図を示す。方法は、医師用デバイスが、後の時点で再度医療データへのアクセスを得るために、患者用デバイスから読み出されたデータ要求情報を記憶することができること回避するよう、受信されたデータ要求が既に以前に使用されたことがある古いデータ要求情報に基づくかどうかを判定するためにデータプロバイダによって使用され得る。図９の方法は、データ要求情報が図８を参照して記載された方法により生成されている実施形態において使用され得る。

最初に、ステップＳ３０で、データプロバイダは、例えば、上記の医師用デバイスのいずれかのような、他のデバイスから、データ要求を受信する。本実施形態では、医師用デバイスは、データプロバイダに医療データを要求しながら、データ要求情報に含まれる暗号化されたトークンを送信するよう構成される。

次いで、ステップＳ３１で、データプロバイダは、最も最近に受信されたデータ要求からのトークンのために使用されてその暗号解読に成功したキーである前の暗号化キー（Ｋ_Ｎ−１）に所定のハッシュ関数を適用することによって、予想される暗号化キー（Ｋ_Ｎ）を得る。明らかなように、このアプローチは、患者用デバイス及びデータプロバイダの両方に、同じ所定のハッシュ関数及び当初の暗号化キーへのアクセスを有することを求める。

次に、ステップＳ３２で、データプロバイダは、得られたキーを用いて、受信されたトークンを暗号解読し、ステップＳ３３で、暗号解読されたトークンは、バリデーションアルゴリズムによりバリデートされる。ステップＳ３４で、トークンのバリデーションが失敗した場合は、ステップＳ３５で、代わりのキーを確認すべきかどうかが判断される。例えば、データプロバイダによって受信された前のデータ要求から現在のデータ要求の間で、患者用デバイスが、いくつかの理由から使用されていない他のデータ要求情報を生成し表示していることがあり得る。この場合に、現在のデータ要求に含まれるトークンは、データプロバイダによって予想された暗号化キーより後の暗号化キーを用いて暗号化されている。

従って、本実施形態では、バリデーションが失敗する場合に、データプロバイダは、例えば、当初のキー（Ｋ_１）に戻って、バリデーションが成功するまで、又は所定の制限（例えば、時限又は確認されるキーの数）が達成されるまで、夫々のキーについて暗号解読及びバリデーションを試みることによって、ステップＳ３６で代わりのキーを選択して代替の暗号化キーを確認することを続ける。所定の制限が達成される場合に、ステップＳ３５で、プロセスは終了し、データ要求はステップＳ３７で拒絶される。

他方で、バリデーションがステップＳ３４で成功する場合は、ステップＳ３８で、データプロバイダは、キーが既に使用されているかどうかを確認する。本実施形態では、データプロバイダは、受信されたトークンを暗号化するために既に使用されたことがある如何なる暗号化キーについてのキーインデックス（Ｎ）の記録も保持し、現在の暗号化キー（Ｋ_Ｎ）のインデックス（Ｎ）を記憶されている記録と比較して、Ｎ番目の暗号化キー（Ｋ_Ｎ）が既に使用されているかどうかを判定する。

現在の暗号化キー（Ｋ_Ｎ）が既に使用されている場合は、ステップＳ３７でデータ要求は拒絶される。なお、現在の暗号化キー（Ｋ_Ｎ）がデータ要求において未だ使用されていない場合は、ステップＳ３９で、記録は現在のキーインデックスＮにより更新され、ステップＳ４０で、データ要求は許可され、要求されているデータは、要求が受信された医師用デバイスへ供給される。

本実施形態では、データプロバイダは、データ要求トークンを暗号化するために使用された暗号化キーに基づきデータ要求を許可すべきか否かを判断するが、他の実施形態では、他のアプローチが使用されてよい。例えば、上述されたように、患者用デバイスは、暗号化の有無にかかわらず、データ要求情報の夫々のインスタンスに一意のコードを含めることができる。かかる実施形態では、データプロバイダは、以前に受信された全ての一意のコードの記録を保持し、現在のコードを記憶されている記録と比較して、受信された一意のコードが前のデータ要求において既に含まれているかどうかを判定することができる。

図８及び９を参照して記載されたような方法は、医師用デバイスが、以前に入手したデータ要求情報によって許可されたデータアクセス期間が経過すると、医療データへのアクセスを回復するために新しいデータ要求情報を入手しなければならないことを確かにするために使用され得る。これは、医療データへのアクセスに対する更なる制御を患者用デバイスのユーザに与える。

図１０は、本発明の実施形態に従って、認証を実行するデバイスを選択する方法を説明するフロー図を示す。方法は、例えば、図４、５及び６を参照して上述されたように、データ要求を許可するために認証が必要とされる場合に、上記のシステムのいずれかにおけるデータプロバイダによって使用され得る。

最初に、ステップＳ４１で、データプロバイダは、患者用デバイス又は医師用デバイスを特定する認証デバイス情報を含むデータ要求を受信する。認証デバイス情報は、例えば、患者用デバイス又は医師用デバイスに割り当てられている一意のデバイス識別子であることができる。代替的に、認証デバイス情報は、どのデバイスに認証要求が送信されるべきかを示す値を持ったフラグであることができる。例えば、‘０’の値は、認証要求が患者用デバイスへ送信されるべきことを示してよく、一方、‘１’の値は、認証要求が医師用デバイスへ送信されるべきことを示してよい。

ステップＳ４２で、データプロバイダは、受信された認証デバイス情報に基づき、認証を行うデバイスを選択する。次いで、ステップＳ４３で、認証要求は、図６のステップＳ１５と同じように、選択されたデバイスへ送信される。

本発明の実施形態は、患者用デバイスがＵＲＬ及びデータ要求トークンの形で医師用デバイスへデータ要求情報を供給するものとして記載されてきた。しかしながら、本発明の実施形態は、データ要求情報としてのトークン及びＵＲＬの使用に制限されない。例えば、他の実施形態では、データ要求情報は、データ要求トークンなしでＵＲＬを有し、ＵＲＬは、データがアクセスされ得るデータプロバイダ１３０上のディレクトリへ直接リンクする。このアプローチは、データ要求トークンの必要性なしに、単純にＵＲＬへナビゲートすることによって、デバイスが医療データを要求することを可能にすることができる。更に、他の実施形態では、データプロバイダ１３０の位置は、医療データを要求するエンティティに予め知られていてよい。これは、データプロバイダ１３０へリンクするＵＲＬがデータ要求情報から省略され得ることを意味する。

明らかなように、語「有する(comprising)」は、他の要素又はステップを除外せず、単称（冠詞a又はanの使用）は、複数個を除外しない。単一のプロセッサは、特許請求の範囲において挙げられている複数の項目の機能を満たしてよい。特定の手段が相互に異なる従属請求項において上げられているという単なる事実は、それらの手段の組み合わせが有利に使用され得ないことを示すものではない。特許請求の範囲における如何なる参照符号も、特許請求の範囲の適用範囲を制限するものとして解釈されるべきではない。

特許請求の範囲は、本願において特徴の特定の組み合わせに編成されているが、当然ながら、本発明の開示の適用範囲は、いずれかの請求項において目下請求されているのと同じ発明に関連しようとしなかろうと、そして、本発明と同じ技術的課題のいずれか又は全てを軽減しようとしなかろうと、ここで明示的に又は暗示的に開示されているあらゆる新規の特徴若しくは特徴のあらゆる新規の組み合わせ、又はその一般化も含む。本願は、これによって、新しい請求項が、本願の又はそれから派生したあらゆる別の出願の手続の間に、係る特徴及び／又は特徴の組み合わせに編成されてよいことを告示する。

ＰＨＲからのデータを共有するには、ユーザは多数のステップを完了しなければならない。通常、患者がＰＨＲからのデータを共有することを可能にするよう、ヘルスケア機関は、登録された患者がログインして、ＰＨＲとの健康情報の交換を可能にするＰＨＲを組み込んだオフラインのアプリケーションを作成することができる。アプリケーションは、ＰＨＲからの患者データにアクセスするために医師がログインするためのログインウィンドウを更に有することができる。医師は、アプリケーションにログインして、一意の患者ＩＤを用いて特定の患者を選択することができる。アプリケーションは、対応するＰＨＲ記録からデータを引き出して、それを医師に示す。
国際公開第２０１２／１０７２７５号パンフレット（特許文献１）からは、サーバシステム、ユーザ端末及びハードウェアトークンを有し、データ記録へのセキュアアクセスを提供するシステムが知られる。サーバシステムは、複数のデータ記録を記憶する記憶手段（Ｉ）を有する。データ記録（２）は、該データ記録（２）に対応するハードウェアトークン（６０）と共有される一連の機密（１４）と関連付けられている。サーバシステム（ＩＯＯ）は、ユーザ認証情報（３）を記憶するよう更に構成される。ユーザ認証手段（１０）は、ユーザ端末（２００）からユーザの認証クレデンシャル（ＩＩ）を受信し、該ユーザを、ユーザの認証クレデンシャル及び記憶されている認証情報（３）に基づき、権限を付与されたユーザとして認証するよう設けられる。機密受信手段（９）は、ハードウェアトークン（６０）によって露わにされる機密（１３）の表示と、前記ハードウェアトークンに対応するデータ記録を特定する情報とを端末から受信するよう設けられる。マーキング手段（１２）は、未使用の機密（ｓ３）を使用済みとしてマークするよう設けられる。
国際公開第２０１２／１０４７７１号パンフレット（特許文献２）からは、レポジトリ（ＲＥＰ）において記憶されている細心の注意を払うべき医療データに安全にアクセスするための方法及びシステム、レジストリ、レポジトリ並びにコンピュータプログラム製品が知られる。レポジトリ内のセキュリティが重要なデータ（ＳＤ）にアクセスする前に、別のレジストリ（ＲＥＧ）による登録問い合わせが、例えば、バーコードの形で、限られた一時的な有効性を有するセキュリティトークン（ＰＳ）を得るために、実行されるべきである。データソース（Ｑ）及び／又はデータシンク（Ｓ）は、次いで、インデックスモジュール（４２）が、レポジトリ（ＲＥＧ）に関して問い合わせられたデータ記録にインデックスを付すように、セキュリティが重要なデータ（ＳＤ）にアクセスするためにセキュリティトークン（ＰＳ）を使用することができる。
国際公開第２０１２／１０７２７５号パンフレット 国際公開第２０１２／１０４７７１号パンフレット

データ要求情報は、例えば、ユニフォーム・リソース・ロケータ（ＵＲＬ；Uniform Resource Locator）の形で、直接リンクを有することができる。代替的に、いくつかの実施形態では、データ要求情報は、医療データに割り当てられた一意の識別子であることができる。例えば、異なる識別子は、異なる患者ごとの医療データへ割り当てられ得、異なる識別子は、同じ患者の医療データの予め定義されたサブセットへ割り当てられ得る。夫々の識別子は、データベースにおいて記憶され、対応する医療データの知られている場所を特定する情報と相互参照され得る。前記第２モジュールは、医療データを前記データプロバイダに要求するために、前記第１モジュールから識別子を入手し、データベースにクエリを行って、対応する医療データの前記知られている場所を特定する情報を読み出すことができる。データベースは、前記第２モジュールにおいて局所的に記憶されてよく、あるいは、遠隔からアクセスされてよい。更なる代替案として、いくつかの実施形態では、前記第２モジュールは、一意の識別子を前記データプロバイダへ送信することによって医療データを要求することができ、前記データプロバイダは、上述されたようにデータベースにクエリを行うことによって、医療データを読み出すことができる。代替的に、一の識別子の代わりに、データ要求情報は、他の方法で患者の医療データのサブセットを識別してよい。例えば、データ要求情報は、患者のごく近い親戚が罹患した病気に関する情報に関する家族既往歴データの要求、又は最近（例えば、６ヶ月前から今日までの期間）の患者の医療データを含む最近の患者データの要求といった、特定のサブセットを要求するクエリを含んでよい。

前記第１モジュールは、データ要求情報に１つ以上のアクセスパラメータを含めるよう構成され、該アクセスパラメータは、如何にして医療データが前記第２モジュールと共有されるのかに関するパラメータを含み、前記第２モジュールは、医療データを要求する場合にアクセスパラメータを前記データプロバイダへ送信するよう構成され、前記データプロバイダは、アクセスパラメータに基づき前記第２モジュールによる医療データへのアクセスを制御するよう構成される。前記１つ以上のアクセスパラメータは、前記第２モジュールが医療データにアクセスすることを許される期間を定義する期間パラメータ、及び／又は医療データに含まれる複数のデータ要素のうちのどのデータ要素が前記第２モジュールによってアクセスされ得るのかを特定するデータ要素パラメータを含むことができる。

本発明の他の態様に従って、データプロバイダとして使用される装置が提供される。当該装置は、患者に対応する医療データを検索するよう構成されるコントローラと、認証を要求するよう構成される認証モジュールと、前記第１モジュール及び前記第２モジュールと通信するよう構成される通信モジュールとを有する。医療データへのアクセスを与えるよう前記第２モジュールから前記通信モジュールを通じて受信された要求に応答して、前記コントローラは、前記通信モジュールを通じて前記第１モジュール又は前記第２モジュールに認証を要求し、認証が成功したかどうかを判定するように前記認証モジュールを制御するよう構成され、成功した認証に応答して、前記コントローラは、前記要求されている医療データへのアクセスを前記通信モジュールを通じて前記第２モジュールへ与えるよう構成される。前記コントローラは、前記アクセスパラメータに基づき前記第２モジュールによる前記医療データへのアクセスを制御するよう更に構成される。

本発明の他の態様に従って、医療データを提供する方法が提供される。当該方法は、前記医療データへのアクセスを与えるための要求を受けるステップと、前記要求のためのアクセスパラメータを供給するステップと、前記医療データへのアクセスのための前記要求に応答して、第１モジュール又は第２モジュールに認証を要求するステップと、認証が成功したかどうかを判定するステップと、成功した認証に応答して、前記アクセスパラメータに基づき前記要求されている医療データへのアクセスを与えるステップとを有する。

Claims (14)

1. 患者に対応する医療データへのアクセスを管理するシステムであって、
   前記医療データへのアクセスを提供するよう構成されるデータプロバイダと、
   前記データプロバイダに前記医療データへのアクセスを要求するためのデータ要求情報を供給するよう構成される第１モジュールと、
   前記第１モジュールから前記データ要求情報を入手し、該入手したデータ要求情報に基づき前記データプロバイダに前記医療データへのアクセスを要求するよう構成される第２モジュールと
   を有し、
   前記データプロバイダは、前記要求されている医療データが対応する前記患者の認証を要求することによって、前記医療データにアクセスするための前記第２モジュールからの要求に応答するよう構成され、認証の成功に応答して前記要求されている医療データへのアクセスを前記第２モジュールへ与えるよう構成される、
   システム。
2. 前記第１モジュールは、前記データ要求情報に１つ以上のアクセスパラメータを含めるよう構成され、該アクセスパラメータは、如何にして前記医療データが前記第２モジュールと共有されるのかに関するパラメータを含み、
   前記第２モジュールは、前記医療データへのアクセスを要求する場合に前記アクセスパラメータを前記データプロバイダへ送信するよう構成され、
   前記データプロバイダは、前記アクセスパラメータに基づき前記第２モジュールによる前記医療データへのアクセスを制御するよう構成される、
   請求項１に記載のシステム。
3. 前記１つ以上のアクセスパラメータは、
   前記第２モジュールが前記医療データにアクセスすることを許される期間を定義する期間パラメータ、及び／又は
   前記医療データに含まれる複数のデータ要素のうちのどのデータ要素が前記第２モジュールによってアクセスされ得るのかを特定するデータ要素パラメータ
   を含む、請求項２に記載のシステム。
4. 前記データ要求情報は、前記データプロバイダへリンクするユニフォーム・リソース・ロケータ（ＵＲＬ）を含み、前記第２モジュールは、前記ＵＲＬへナビゲートすることによって前記医療データへのアクセスを要求するよう構成される、
   請求項１乃至３のうちいずれか一項に記載のシステム。
5. 前記第１モジュールは、前記データ要求情報を表示するよう構成され、
   前記第２モジュールは、前記第１モジュールの画像を捕捉し、該捕捉された画像を処理して前記表示されたデータ要求情報を検出するよう構成される、
   請求項１乃至４のうちいずれか一項に記載のシステム。
6. 前記データ要求情報は、前記第１モジュール又は前記第２モジュールを特定する認証デバイス情報を含み、前記データプロバイダは、前記認証デバイス情報によって特定される前記第１モジュール又は前記第２モジュールに認証を要求するよう構成され、且つ／あるいは、
   前記データプロバイダは、認証要求を前記第１モジュールへ送信し、認証情報を前記第１モジュールから受信し、該受信された認証情報を前記患者についての既知の認証情報と比較して認証が成功したかどうかを判定することによって、認証を要求するよう構成される、
   請求項１に記載のシステム。
7. 前記第２モジュールから前記医療データへのアクセスのための要求を受信した後、前記データプロバイダは、前記データ要求情報が前のデータ要求において既に使用されているかどうかを判定し、前記データ要求情報が前のデータ要求において使用されていないと決定される場合にのみ前記要求されている医療データへのアクセスを前記第２モジュールへ与えるよう構成される、
   請求項１又は６に記載のシステム。
8. 前記第１モジュールは、保護されたトークンを入手し、該保護されたトークンを前記データ要求情報に含めるよう構成され、前記保護されたトークンは、暗号化キーを用いて保護されているトークンを有し、
   前記データプロバイダは、前記第２モジュールから前記保護されたトークンを受信し、予想される暗号化キーを用いて前記保護されたトークンを処理し、前記予想される暗号化キーを用いて前記トークンの入手に成功するならば、前記予想される暗号化キーが以前に使用されなかった場合に前記データ要求情報が前のデータ要求において使用されていないと決定するよう構成される、
   請求項７に記載のシステム。
9. 前記データプロバイダは、現在のデータ要求より前に最も最近に受信されたデータ要求において使用された暗号化キーである前の暗号化キーに暗号化アルゴリズムを適用することによって、前記予想される暗号化キーを得るよう構成される、
   請求項８に記載のシステム。
10. 請求項１乃至９のうちいずれか一項に記載のシステムにおいて第１モジュールとして使用される装置であって、
    前記データプロバイダに前記医療データへのアクセスを要求するための前記データ要求情報を生成するよう構成されるデータ要求情報生成部と、
    前記生成されたデータ要求情報を前記第２モジュールへ供給するよう構成されるデータ要求情報提供モジュールと
    を有する装置。
11. 請求項１乃至９のうちいずれか一項に記載のシステムにおける前記第１モジュールの制御方法であって、
    前記データプロバイダに前記医療データへのアクセスを要求するための前記データ要求情報を生成するステップと、
    前記データ要求情報を前記第２モジュールへ供給するステップと
    を有する制御方法。
12. 請求項１乃至９のうちいずれか一項に記載のシステムにおいてデータプロバイダとして使用される装置であって、
    患者に対応する前記医療データを検索するよう構成されるコントローラと、
    認証を要求するよう構成される認証モジュールと、
    前記第１モジュール及び前記第２モジュールと通信するよう構成される通信モジュールと
    を有し、
    前記医療データへのアクセスを与えるよう前記第２モジュールから前記通信モジュールを通じて受信された要求に応答して、前記コントローラは、前記通信モジュールを通じて前記第１モジュールに認証を要求し、認証が成功したかどうかを判定するように前記認証モジュールを制御するよう構成され、成功した認証に応答して、前記コントローラは、前記要求されている医療データへのアクセスを前記通信モジュールを通じて前記第２モジュールへ与えるよう構成される、
    装置。
13. 医療データを提供する方法であって、
    前記医療データへのアクセスを与えるための要求を受けるステップと、
    前記医療データへのアクセスのための前記要求に応答して、第１モジュール又は第２モジュールに認証を要求するステップと、
    認証が成功したかどうかを判定するステップと、
    成功した認証に応答して、前記要求されている医療データへのアクセスを与えるステップと
    を有する方法。
14. 請求項１乃至９のうちいずれか一項に記載のシステムにおいて第２モジュールとして使用される装置であって、
    前記第１モジュールからデータ要求情報を得るよう構成されるデータ要求情報検出部と、
    前記データプロバイダと通信する通信モジュールと、
    前記得られたデータ要求情報に基づき前記医療データへのアクセスを前記データプロバイダに要求するように前記通信モジュールを制御するよう構成されるコントローラと
    を有する装置。

Images