医療データを処理する方法及びシステム
本発明は、医療データにアクセスするための解読キーを所持し又は該解読キーへのアクセスを有する信頼エージェントにより医療データを処理する方法に関するものである。医療データへのアクセスを要求するリクエスタからリクエストが受信される。上記リクエスト又はリクエスタ又は両方に関するデータを含むログが発生される。最後に、上記リクエスタに当該医療データへのアクセスが付与される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、医療データ（healthcare data）へアクセスするための解読キーを所持し又は該解読キーに対するアクセスを有する信頼されるエージェント（信頼エージェント）により医療データを処理する方法に関する。本発明は、更に、医療データを処理するように構成された信頼エージェントにも関し、該信頼エージェントは医療データにアクセスするための解読キーを所持し又は該解読キーに対するアクセスを有する。本発明は、更に、上記信頼エージェントにより処理される医療データへアクセスするためのリクエストを発生するリクエスト発生器を有するリクエスタ、及び上記信頼エージェントからログを受信するためのレシーバを有するサーバにも関する。
【背景技術】
【０００２】
情報及び通信技術の進歩は、医療分野に大きな利益をもたらすと期待される。相互運用可能な電子健康医療記録（ＥＨＲ）システムの導入は、医療システムの費用を低減すると共に治療の全体的品質を向上させることができる一方、遠隔患者管理（ＲＰＭ）サービスは患者が病院に留まる時間を限られたものにするであろう。それにも拘わらず、現在のところ、ＥＨＲ及びＲＰＭは、むしろ小規模でしか使用されていない。異なるシステムの統合及び手配の問題に関する課題とは別に、情報の保全（セキュリティ）及び私的秘密（プライバシ）に関する不安が、配備されたシステムの不足の主たる理由である。例えば、ＥＨＲシステムは、遵守すべき厳格なセキュリティ及びプライバシ規則（米国におけるＥＵ指令９５／４６又はＨＩＰＡＡ等）に直面している。
【０００３】
近代的医療通信アーキテクチャは、開放された相互接続された環境である傾向がある。機密的患者記録は、最早、医療提供者内で物理的に隔離された、データ及びシステムを防護するために物理的保全手段をとることができるメインフレーム上には存在しない。むしろ、患者のファイルは、家庭医、医療専門家及び非医療提供者さえにも対する分散されたアクセスを可能にするために、データが部分的に信頼のおけないサーバに外部委託され又は斯かるサーバ上で処理されるような環境で保持される。データをデータベースサーバ内に閉じ込め、データに対するアクセスを許可するために伝統的なアクセス制御モデルを使用するような、現在採用されているサーバ中枢的保護モデルは、新しい医療設備の要求に効率的に対処することができない。
【０００４】
異なる医療提供者の間での又は外部当事者との記録の共有を可能にするために、データ中枢的保護を容易にするエンド・ツー・エンド（終端間）保全技術を採用することができる。この場合、データは暗号的に保護され、外部委託され又はネットワーク上を自由に浮遊することさえ可能とされる。秘密性、完全性及び信憑性を提供するために異なるネットワークに依存するというよりは、データは通信の端点で保護される。これは、消費者電子機器のドメインで権利管理技術−デジタル権利管理（ＤＲＭ）を適用し、ビジネスドメインで企業権利管理（ＥＲＭ）を適用することにより達成することができる。このようなシステムでは、公開されるＤＲＭ保護されたデータは暗号化され、ライセンスサーバは、要求するユーザに対して、これらユーザが当該データにアクセスするための充分な権利を有する場合はライセンスを発行する。しかしながら、この技術により解決されない特定の問題は、採用された保護モデルに無関係に、緊急時に電子患者記録に対する即時的アクセスを保証するということである。上記のようなＤＲＭ／ＥＲＭシステムは、全ての必要とされるアクセス権を満たす要求者のみに医療データに対するアクセスを付与することに関しては非常に信頼性があるが、斯様なシステムは、当該システムの通常の動作の免除（例えば、医療提供者が医療データへの即座のアクセスを必要とする場合）を要するような緊急状況に対処することができない。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明の目的は、当該システムの通常の動作の免除を示すと共に、例えば病院等の緊急の医療提供者が、該医療提供者に当該医療データに対するアクセスを許可する通常の権利は存在しないが、該医療データへの即座のアクセスを必要とするような状況に対処することができるという点で、確実であるが同時に柔軟な医療データを処理する方法を提供することにより、上述した欠点を克服することにある。
【課題を解決するための手段】
【０００６】
一態様によれば、本発明は、医療データにアクセスするための解読キーを所持し又は該解読キーに対するアクセスを有する信頼されるエージェント（信頼エージェント）により医療データを処理する方法であって、
【０００７】
医療データへアクセスすることを要求するリクエスタからリクエスタを入力するステップと、
【０００８】
上記リクエスタ又は上記リクエスタ又はこれら両方に関するデータを含むログを発生するステップと、
【０００９】
上記リクエスタに上記医療データへのアクセスを付与するステップと、
を有する方法に関するものである。
【００１０】
このように、如何なる時点においても、上記リクエスタは医療データにアクセスすることができると同時に、該医療データの秘密性を効率的に保護する。当該医療データは暗号化され、上記信頼エージェントは、リクエスタの素性に基づいて、アクセス（解読）が許可されるかを決定することができる。例えば、当該アクセス方針は、医療データは医療提供者によってのみアクセスすることができるとすることができる。更に、アクセスはログ（記録）され、このことは、当該データにアクセスした医療提供者が、自身の行為に責任があるものとさせる。上記信頼エージェントは、例えば、物理的装置又は信頼される供給元からのソフトウェアアプリケーションとすることができ、標準のインターフェースを有することができる。このことは、複数の供給元が実施化を行うのを可能にすると共に、医療アプリケーションが単一のインターフェースを実施化することも要する。
【００１１】
一実施例において、入力された上記リクエストは、該入力されたリクエストが緊急リクエストであることを通知するデータタグを含む。
【００１２】
このように、医療データにアクセスするための緊急リクエストを処理することができないライセンスサーバ、準拠クライアント等が使用されるデジタル権利管理（ＤＲＭ）クライアントアプリケーションのような前述した従来技術のアプリケーションとは異なり、緊急医療者（例えば、病院）は、該医療者がアクセスに対する通常の権利を有していない場合でさえ、該医療者がアクセスしたいデータにアクセスすることを許可するライセンスを許諾される。このような緊急アクセスは、当該医療データのセキュリティの犠牲のもとであり得、斯かるセキュリティは、確かに、重要なフィーチャであるが、それでも患者の安全よりは重要ではない。何故なら、斯様な医療データへの緊急アクセスは患者の生命を救い得るからである。
【００１３】
一実施例において、前記リクエスタから入力されるリクエストは、当該医療データにアクセスするための解読キーの要求を含み、該リクエスタに当該医療データへのアクセスを付与するステップは、要求された解読キーを該リクエスタに送るステップである。
【００１４】
従って、信頼エージェントが、リクエストが入力された全てのクライアントのデータを解読する必要がない場合は、ボトルネックが回避される。斯かる解読は、クライアントアプリケーションで行われる。
【００１５】
一実施例において、前記リクエスタから入力されるリクエストは、暗号化された形態の上記の要求された医療データを含み、該リクエスタに該医療データへのアクセスを付与するステップは、解読された形態の該医療データを該リクエスタに送るステップである。
【００１６】
この構成は、上記信頼エージェントを、デジタル権利管理及びデータ解読をサポートしない旧来のシステムと相互運用するのを可能にする。この場合、前記暗号化されたデータはクライアントアプリケーションにオフラインで記憶される。
【００１７】
一実施例において、入力されたリクエスタに続いて、当該エージェントは暗号化された形態の医療データをサーバから取得すると共に、該医療データを解読し、上記リクエスタに該医療データへのアクセスを付与するステップは、解読された該医療データを上記リクエスタに送るステップである。
【００１８】
この実施例は、先の実施例と同様の利点を提供する。しかしながら、この実施例における上記医療データは中央データベースに記憶される。
【００１９】
一実施例において、当該方法は、前記ログを再吟味のためにサーバに送るステップを更に有する。
【００２０】
このように、前記信頼エージェントは、リクエスト、リクエスタに関する全ての必要な詳細を記録することができる。これは、日付及び時間等の前後関係データ、要求されたデータ等の当該リクエストに含まれる情報、使用されている医療アプリケーション又は装置に対するログイン証明等のリクエスタに関する情報、ＩＰアドレス等の当該装置に関する情報とすることができる。
【００２１】
一実施例において、ライセンスは、当該医療データにアクセスするための解読キー及び関連するライセンス規則を含み、当該リクエスタがデジタル権利管理（ＤＲＭ）クライアントアプリケーション又は企業権利管理（ＥＲＭ）クライアントアプリケーションである場合、斯かるＤＲＭ又はＥＲＭクライアントアプリケーションに当該医療データへのアクセスを付与するステップは、ライセンス解読キー及び関連するライセンス規則を該ＤＲＭ又はＥＲＭクライアントアプリケーションに送るステップである。
【００２２】
一実施例において、当該医療データは文書キー（document key）により保護され、当該ライセンスが、当該保護された医療データに対する緊急キーＫＥｍにより暗号化された文書キーを有する場合、該緊急キーＫＥｍは後に全ての信頼エージェントに分配される。
【００２３】
一実施例において、前記ライセンスは、保護された医療データに付加される。
【００２４】
一実施例において、前記緊急ライセンス及び保護された医療データはＤＲＭ又はＥＲＭに送られ、緊急リクエストの際、斯かるＤＲＭ又はＥＲＭには、文書解読キーを解読するように適合化された緊急キーＫＥｍが更に供給される。
【００２５】
他の態様によれば、本発明は、コンピュータ上で実行された場合に、処理ユニットに上述した方法のステップを実行するように命令するコンピュータプログラムに関するものである。
【００２６】
更に他の態様によれば、本発明は、医療データにアクセスするための解読キーを所持し又は該解読キーに対するアクセスを有し、該医療データを処理するように構成された信頼エージェントであって、
【００２７】
医療データへアクセスすることを要求するリクエスタからリクエストを受信するレシーバと、
【００２８】
上記リクエスト又は上記リクエスタ又はこれら両方に関するデータを含むログを発生するログ発生器と、
【００２９】
受信された上記リクエストを処理し、該処理の結果、前記リクエスタに前記医療データに対するアクセスを付与するプロセッサと、
を有する信頼エージェントに関するものである。
【００３０】
更に他の態様によれば、本発明は、前記信頼エージェントにより処理される医療データにアクセスするためのリクエストを発生するリクエスト発生器を有するリクエスタに関するもので、上記リクエスト発生器は、更に、該発生されたリクエストが緊急リクエストであることを通知するデータタグを発生するように構成される。
【００３１】
更に他の態様によれば、本発明は、前記信頼エージェントからログを受信するレシーバと、該受信されたログを記憶するメモリとを有するサーバであって、
【００３２】
前記メモリは、医療データ、又は医療データにアクセスするための解読キー、又は前記医療データにアクセスするための前記解読キー及び関連するライセンス規則を有するライセンス、又はこれらの組み合わせを更に記憶しており、
【００３３】
信頼される前記サーバは、複数の前記信頼エージェントを操作、供給及び管理し、該操作は、前記信頼エージェントから前記ログを受信することに応答して、斯かる信頼エージェントに要求された解読キーを供給することにより前記医療データに対するアクセスを付与することを含む。
【００３４】
本発明の上記態様の各々は、他の態様の何れとも組み合わせることができる。本発明の、これら及び他の態様は、後述する実施例から明らかとなり、斯かる実施例を参照して説明される。
【図面の簡単な説明】
【００３５】
【図１】図１は、本発明による方法のフローチャートを示す。
【図２】図２は、本発明による信頼エージェント、リクエスタ及びサーバを線図的に示す。
【図３】図３は、ＤＩＣＯＭ（Digital Imaging and Communication in Medicine）に準拠したＤＲＭシステムのための暗号化されたファイル及びライセンスを示す。
【図４】図４は、古いＤＲＭ設備及び新しい緊急設備からなる、緊急アクセスに対するサポートを備える強化されたＤＲＭ設備を示す。
【図５】図５は、準拠クライアントであると見なされ得るリクエスタによる緊急データのアクセスを示す。
【図６】図６は、非準拠クライアントであると見なされ得るリクエスタによる緊急データのアクセスを示す。
【発明を実施するための形態】
【００３６】
以下、本発明の実施例を、図面を参照して例示としてのみ説明する。
【００３７】
図１は、医療データ（healthcare data）にアクセスするための解読キーを所持する又は該解読キーへのアクセスを有する信頼エージェント（trusted agent）により医療データを処理する本発明による方法のフローチャートを示す。該医療データは、患者及び該患者の医療履歴を識別するデータであり得る。上記信頼エージェントは、例えば信頼される製造供給元（vendor）からのソフトウェアアプリケーション又は物理的装置であり得る。好ましくは、信頼エージェントは、複数の製造供給元が実施を行うのを可能にすると共に、医療アプリケーションが単一のインターフェースを実施化するのを要求するような標準インターフェースを有するものとする。上記医療アプリケーションは、通常の医療アプリケーションとして、又は緊急医療アプリケーションとして考えことができる。通常の医療アプリケーションは、保護された医療データにアクセスすることができなければならず、例えばアクセス制御エンジン、デジタル権利管理（ＤＲＭ）クライアント等の方針決定及び執行機能を有する。更に、典型的には、該通常の医療アプリケーションは、結果として保護されたデータに対するアクセスを許可し又は許可しない方針決定及び執行機能となるような証明（credentials）、即ちアイデンティティ、解読キー等を有する。上記信頼エージェントは、上記医療アプリケーションのように必ずしも同一の装置上に配備される必要はないことに注意されたい。
【００３８】
緊急医療アプリケーションは、医療データに対する緊急又は"迅速化された"アクセスが必要な場合である。該緊急医療アプリケーションは、典型的には、保護されたデータへのアクセスを有するが、アクセスを許可する証明は有さない。下記のステップが、斯様な場合を扱う。
【００３９】
ステップ（Ｓ１）１０１において、リクエストがリクエスタ（即ち、この場合は緊急医療アプリケーション）から信頼エージェントに送られるが、該信頼エージェントは、前述したように、当該医療データにアクセスするための解読キーを所持するか又は該解読キーに対するアクセスを有する。受信される上記リクエストは、該受信されたリクエストが緊急リクエスト又は"迅速化される"アクセスのリクエストであることを通知するデータタグを含むことができる。
【００４０】
ステップ（Ｓ２）１０３において、上記信頼エージェントは、上記リクエスト又は上記リクエスタ又はこれら両方に関するデータを含むログ（記録）を発生する。該ログに含まれる情報は、例えば、上記リクエストがなされた日付及び時間等の前後関係データ、要求されたデータのタイプ等の上記リクエストに含まれる情報、例えば当該医療アプリケーションに対するログイン証明又は上記リクエスタ若しくは使用されている装置のＩＤ番号等の上記リクエスタに関する情報、ＩＰアドレス等の当該装置に関する情報等であり得る。
【００４１】
一実施例において、上記ログは、次いで、再吟味のためにサーバ、例えば病院内の中央サーバに送られる（ステップ（Ｓ３）１０５）。
【００４２】
最後に、上記リクエスタに上記医療データに対するアクセスが付与される（ステップ（Ｓ４）１０７）。
【００４３】
一実施例において、前記受信されたリクエストは当該医療データにアクセスするための解読キーの要求を含み、その場合、上記リクエスタに医療データへのアクセスを付与する上記ステップ（Ｓ４）１０７は、要求された解読キーを上記リクエスタに送ることにより実行される。このように、信頼エージェントは、リクエストが受信された全てのクライアントのデータを解読する必要はない。何故なら、解読はクライアントアプリケーションにおいて行われ、障害が回避されるからである。
【００４４】
他の実施例において、上記リクエスタから受信されるリクエストは、暗号化された形態の要求される医療データを含み、前記リクエスタに医療データへのアクセスを付与する前記ステップは、解読された形態の該医療データを上記リクエスタに送るステップを含む。これは、該信頼エージェントを、デジタル権利管理及びデータ解読をサポートしない旧来のシステムと相互運用するのを可能にする。この場合、暗号化されたデータはオフラインでクライアントアプリケーションに記憶される。
【００４５】
一実施例において、前記リクエスタはＤＲＭクライアントアプリケーション又は企業権利管理（ＥＲＭ）クライアントアプリケーションであり、その場合、ライセンスが当該医療データにアクセスするための解読キー及び関連するライセンス規則を有する。該ＤＲＭ又はＥＲＭクライアントアプリケーションに当該医療データへのアクセスを付与する前記ステップは、上記ライセンス解読キー及び関連するライセンス規則を該ＤＲＭ又はＥＲＭクライアントアプリケーションに送るステップを有することができる。これは、後に詳述する。
【００４６】
一実施例においては、前記ログとの交換で新たなキーが獲得される。これは、無制限なアクセスを得るために敵対者によりシステムが"切断され"ないことを保証し、付加的な安全性を提供する。何故なら、上記サーバは、新しく信用できるログ情報を受信した場合にのみ信頼エージェントに緊急キーを分配するからである。
【００４７】
図２は、医療データを処理するように構成されると共に医療データにアクセスするための解読キーを所持し又は該解読キーに対するアクセスを有する信頼エージェント２００、リクエスタ２２０及びサーバ２１０を線図的に示す。
【００４８】
リクエスタ２２０はリクエスト発生器（R_G）２２１を有し、該リクエスト発生器は当該医療データにアクセスするためのリクエスト２２３を発生すると共に、発生されたリクエスト２２３が緊急リクエストであることを通知するデータタグ２２２を更に発生するように構成されている。発生されたリクエスト２２３及びデータタグ２２２は、次いで、通信チャンネル２２４（有線又は無線であり得る）を介して信頼エージェント２００に供給され又は送信される。
【００４９】
信頼エージェント２００は、受信器（Ｒ）２０３、ログ発生器（L_G）２０２及びプロセッサ（Ｐ）２０１を有している。受信器（Ｒ）２０３は、医療データにアクセスすることを要求するリクエスタ２００から上記リクエスト２２３を受信するように構成されている。ログ発生器（L_G）２０２はログ２０４を発生するように構成され、該ログは、先に図１において説明したように、上記リクエスト及び上記リクエスタ又はこれら両方に関するデータを有する。プロセッサ２０１は、受信されたリクエスト２２３を処理するように構成されている。該処理は、サーバ２１０との通信、即ち、例えば医療データにアクセスするための解読キーを要求することによる該サーバとの通信を含む。また、該処理は、要求された解読キーを上記リクエスタに供給する、又は解読された形態の医療データを上記リクエスタに供給することを含む（図１における説明参照）。
【００５０】
ここに図示されたサーバ２１０は通信チャンネル２０５を介して信頼エージェント２００と通信するが、上記通信チャンネルは有線通信チャンネル又は無線通信チャンネルとすることができる。サーバ２１０は、前記ログ２０４を信頼エージェント２００から受信するための受信機（Ｒ）２１１と、受信されたログを記憶するためのメモリ２１２とを有している。該メモリ２１２は、医療データ、又は医療データにアクセスするための解読キー、医療データにアクセスするための関連するライセンス規則を有するライセンス解読キー、又はこれらの組み合わせも記憶している。該サーバは、更に、複数の前記信頼エージェントを操作するように構成され、該操作は、前記信頼エージェントからの前記ログの受信に応答して、該信頼エージェントに、要求された解読キーを供給することにより上記医療データに対するアクセスを付与することを含む。これは、後に詳述する。
【００５１】
図３は、本発明による一実施例を図示し、如何にして本発明をＤＩＣＯＭ（Digital Imaging and Communication in Medicine）に適用することができるかを示している。
【００５２】
ＤＲＭシステムは、医療情報のエンド・ツー・エンド秘密性を保証し、宛先に対する発信元制御を提供する。図３に示されたＤＩＣＯＭファイルのためのＤＲＭシステムは、"National Electric Manufacturers Association (NEMA), Digital Imaging and Communications in Medicine (DICOM), part 15: Security and system management profiles Annex E.1, 2007"（参照により本明細書に組み込まれる）に開示されているような、暗号メッセージ構文及びＤＩＣＯＭ識別不能化プロファイルの緩和バージョンを使用する。このように、保護されなければならないＤＩＣＯＭファイルの属性は、内容暗号化キー（content-encryption key）により暗号化される。次いで、所要のキー材料を持つライセンスが埋め込まれる。これは、規格により提供されるツールが使用されるような方法で実施され、従って、依然として後方互換性を保証する。
【００５３】
セキュリティの観点からは、このＤＲＭ方式は、医療社会の異なるユーザのプライバシ及びデータの分配に対する管理に関しては改善となる。しかしながら、医療セキュリティ解決策が医療専門家により受け入れられるためには、緊急アクセスの可能性を含むことが必須である。
【００５４】
ライセンスサーバ、準拠したクライアント等が使用される医療データ（healthcare data, medical data）に対するＤＲＭ保護を伴う環境を仮定する。公開されるＤＲＭ保護データは暗号化され、ライセンスサーバは、要求するユーザが斯かるデータにアクセスするための充分な権利を有するならば、これらユーザに対してライセンス（内容の使用権を含む）を発行する。従って、緊急アクセスは、該緊急アクセスが当該システムの通常の動作の例外を示すという点で、処理するのが困難である。緊急医療提供者には、好ましくは、該提供者がアクセスしたいデータを解読するライセンスを、該提供者が該データに対する通常の権利を有していなくても許諾されるべきである。従って、このようなアクセスの正当性は、最終的にデータのプライバシを保証するために後に検証されねばならない。この場合、緊急アクセスのログ記録が必要となる。
【００５５】
前述したように、緊急アクセスの管理の課題に対する解決策は、緊急ライセンスを発行し、そのような出来事（イベント）をログ記録することである。これは、ライセンスサーバ２１０（図２参照）により全ての信頼エージェント２００（図２参照）に対し緊急キーＫＥｍを分配することにより実施することができる。内容キーのＫＥｍによる暗号化からなるキーライセンスは、全ての新たに保護される医療データと共に埋め込むことができる。緊急アクセスの際には、信頼エージェント２００は上述したようにイベントをログ記録し、当該リクエスタ（例えば、要求するユーザ）が例えばライセンスサーバから許可を得なかったとしても当該データをＫＥｍにより解読する。
【００５６】
緊急アクセスの管理の課題に対する他の解決策は、ＤＲＭの暗号化時にはデータにライセンスを埋め込まないことである。しかしながら、緊急アクセスの際には、リクエスタ２２０（医療提供者であり得る）は信頼エージェント２００を介して適切なサーバ２１０（例えば、ライセンスサーバ２１０）に接触し、緊急ライセンスを要求する。ライセンスサーバ２１０は、信頼エージェント２００のフィーチャを実施化することができる。即ち、信頼エージェント２００の幾つか又は全てのフィーチャが該ライセンスサーバ２１０に組み込まれていると考えることができるか、又は信頼エージェント２００及びライセンスサーバ２１０が図２に示されたように対話することができる。当該イベントはライセンスサーバによりログ記録され、一時的ライセンスが発行される。
【００５７】
信頼エージェント２００がデータの秘密性を果たすべく緊急状況を処理する責任を負うような図２に示した筋書きは、ＤＲＭシステムと並列に配備することができる。これが図４に示され、該図は古いＤＲＭ設備４１３及び新しい緊急設備４００からなる緊急アクセスのためのサポートを伴う強化されたＤＲＭ設備を示している。
【００５８】
図４は緊急アクセスを備えるＤＲＭ設備がどの様に強化されるかを示しているが、これはＤＩＣＯＭに限られると見なされるべきではなく、種々のシステムが対象である。
【００５９】
新たな緊急設備４００は、図２からの前記サーバ２１０（ここでは、緊急権限者（E_A）４０１と称する）及び複数の前記信頼エージェント２００（ここでは、緊急エージェント（E_A_E1〜n）４０２〜４０５と称する）を有する。緊急権限者E_A）４０１はデータ作成者及び消費者とは独立であり、信頼され得る。最後には、該権限者は緊急アクセスの正当性を検証する責任を負う。該権限者は、この処理をサポートするために幾つかの構成要素を操作する。
【００６０】
緊急エージェント（E_A_E1〜n）４０２〜４０５は、リクエスタ４０６が緊急アクセスを要求する場合に該リクエスタにより接触される。緊急エージェント（E_A_E1〜n）４０２〜４０５は、緊急医療提供者にアクセスを付与し、これらのイベントをログ記録する責任を負う。これらエージェントは、緊急権限者（E_A）４０１により、例えば証明を介して信用される。この目的のために、このような構成者の準拠性は、この信用を仮定する前に、緊急権限者（E_A）４０１（前記サーバ２０１に対応する）によりチェックすることができる。緊急エージェント（E_A_E1〜n）４０２〜４０５は、例えばＤＲＭシステム４１３が配備された病院に設置することができる。
【００６１】
緊急権限者（E_A）４０１は、新たな緊急キーの対ＫprivEm(id)及びＫpubEm(id)を発生するように構成することができる。該緊急権限者は、秘密キーＫprivEm(id)を、好ましくは安全に、該権限者の全ての緊急エージェント（E_A_E1〜n）４０２〜４０５に送信する。緊急権限者（E_A）４０１が、この新たな秘密キーが成功裏に分配されたことを確かめたなら、該権限者は対応する公開キーＫpubEm(id)をライセンスサーバ（L_S_1〜n）４０９〜４１２に、これらサーバが保護されたデータに対する緊急ライセンスを作成することができるように、送信する。
【００６２】
緊急権限者（E_A）４０１による上記キーの発生は、例えば病院毎に１つのキー対、日毎に１つのキー対等の異なる方針に従うことができる。他の代替例として、共通の緊急キーを国内レベルで全てのデータに対して使用することもできる。しかしながら、これらの全てのキーは、接触される緊急エージェント又はファイルとは無関係に、緊急アクセスに際してデータの利用可能性が保証されるように、全ての緊急エージェント（E_A_E1〜n）４０２〜４０５により知られていなければならない。秘密キーＫprivEm(id)が、緊急設備の信頼される環境内に留まることが重要である。開示された秘密キーに基づく緊急ライセンスを含む全てのＤＲＭにより保護されたデータの秘密性は、言い換えれば、危うくされる。
【００６３】
ＤＲＭ発行者（Publ.）による元のファイルＦの暗号化に際して、緊急ライセンスLFEmが、結果としてのファイルに埋め込まれる。該ライセンスは、当該ＤＲＭ保護ファイルに対して責任のあるライセンスサーバにより、緊急公開キーＫpubEm(id)についての知識を用いて作成される。結果的な暗号化されたＤＲＭコンテナは、上記元のデータを暗号化された形態で含む。
【００６４】
リクエスタ（例えば、緊急医療提供者）が、自身が既にダウンロードしたファイルＦに対する緊急のアクセスを必要とする場合、該リクエスタは好ましくは最寄りの利用可能な緊急エージェント（E_A_E1〜n）４０２〜４０５に接触する。
【００６５】
図４に示された実施例は、ＤＩＣＯＭに焦点を当てたものである。従って、交換メッセージは、新たなＤＩＣＯＭ緊急アクセスサービスオブジェクト対（ＳＯＰ）クラスとして定義される。
【００６６】
一般的に、ＤＩＣＯＭは、サービスオブジェクト対（ＳＯＰ）クラスにおける情報オブジェクト定義（ＩＯＤ）に適用可能なサービスの組を定義する。ＳＯＰクラスは、正規化された又は複合のＩＯＤに当てはまるかに依存して、正規化されたもの又は複合のものの何れかとなり得る。正規化されたＩＯＤは、一般的に実社会のＤＩＣＯＭモデルにおける単一のエンティティを表す情報オブジェクト定義である。複合ＩＯＤは、実社会のＤＩＣＯＭモデルに含まれる幾つかのエンティティの部分を表す情報オブジェクト定義である。ＳＯＰクラスは、固有の識別子、即ちＳＯＰクラスＵＩＤ、により識別される。ＳＯＰクラス内のサービスが既述されるためには、先ず、参加者の各々に役割を割り当てる必要がある。ピアは、サービスクラスユーザ（ＳＣＵ：即ちクライアント）若しくはサービスクラス提供者（ＳＣＰ：即ちサーバ）の何れかであり得るか、又は両方の役割を同時になす。サービス記述は、当該ＩＯＤに適用され得るコマンドも定義する。既存のコマンド型式は、C-STORE、C-FIND、C-MOVE、C-GET、C-CANCEL及びC-ECHOを含む。
【００６７】
１つのＤＩＣＯＭノードから他のものへコマンドが送られる場合、このコマンドは該コマンドに関わるＳＯＰクラス及びＩＯＤインスタンスに対する参照を含み、追加のデータ集合を添付することができる（当該コマンドのペイロード）。宛先は、コマンド実行ステータス（例えば、失敗、成功等）及びオプションとしての添付ペイロードにより回答する可能性を有する。２つのアプリケーション（アプリケーションエンティティ）が通信したいと欲する場合、これらアプリケーションは、何のサービス（ＳＯＰクラス）を使用としているかについて合意しなければならない。従って、通信確立手順は、連合交渉（association negotiation）と呼ばれるサポートされるＳＯＰクラスの交渉を含む。通信するアプリケーションエンティティのうちの一方が、或るＳＯＰクラスをサポートしない場合、関連するサポートは使用することができない。
【００６８】
ＤＩＣＯＭファイルに方針を含めるために、暗号化された属性データセット（即ち、ＣＭＳエンベロープ）がＤＩＣＯＭファイルに埋め込まれる。新たな属性、即ち開示キー、も導入される。該キーは、属性を保護するために使用されるであろう対称キーを含む。暗号化に際して、下記の処理が生じる。
保護されねばならない全ての属性は、開示キーのキーを含め、スクランブルされる。
当該属性の暗号化されたバージョンを含むＣＭＳエンベロープが、開示キーのものは除き、作成される。該エンベロープの文書暗号化キーは、元の開示キー属性のキーを用いて暗号化される。
ユーザが当該データにアクセスすることを要求した場合、前記ライセンスサーバは、元の開示キー属性を含む、ＤＩＣＯＭ規格に準拠した新たなＣＭＳエンベロープを発生する。該エンベロープの文書暗号化キーは、準拠するクライアント又はユーザの公開キーを用いて暗号化される。
【００６９】
新たなライセンスの作成に際して、流布されるＤＩＣＯＭコンテンツは変更されない。即ち、ライセンスは後の使用のために当該ファイルに添付され得るのみである。前記方針は、ＣＭＳエンベロープ内に保護されない属性として保存される。従って、異なるユーザに対して異なる方針を設定することができる。この解決策は、異なる属性を保護する全てのエンベロープが異なる方針仕様を有することができるという意味で、非常に柔軟なものでもある。
【００７０】
図５はプロトコルを線図的に示し、該図において、準拠クライアント（C_C）４０６と見なすことができるリクエスタ４０６は、ファイルＦ５０１に対するアクセスを、該Ｆに埋め込まれた緊急ライセンス（S1'）５０２を緊急エージェント（E_A_E1〜n）４０２〜４０５に送ることにより要求する。ＤＩＣＯＭでは、これは、上記緊急ライセンスを含むN-ACTIONコマンドとして実施化することができる。前述したように、緊急エージェント（E_A_E1〜n）４０２〜４０５なる用語は、単に図２に示されたような信頼エージェント２１０の一実施例である。また、前述したように、緊急権限者（E_A）４０１は１以上の緊急エージェント（E_A_E1〜n）４０２〜４０５を操作することができ、該緊急エージェントは、なかでも、リクエスタ４０６によるリクエストに応答して前記ログ処理を実行する。
【００７１】
図５に示したプロトコルを再び参照して、上記リクエスタ（C_C）４０６が確かに準拠クライアントであることをチェックした後、該リクエスタ（C_C）４０６に対するログ（S2'）５０３が発生される。緊急権限者（E_A）４０１（図５には図示せず）は、受信された緊急ライセンスを適切な秘密キーを用いて解読する。内容キー（コンテンツキー）を回復した後、上記リクエスタの公開キーを用いて、該リクエスタ（C_C）４０６によってのみ使用されることを意図する新たな一時的ライセンスが構築される。
【００７２】
次いで、新たな一時的ライセンス（S3'）５０４は、リクエスタ（C_C）４０６に送られる。ＤＩＣＯＭでは、これは、上記一時的ライセンスを含むN-EVENT-REPORTコマンドとして実施化することができ、従って、該ライセンスは図３に示したようなＤＩＣＯＭライセンスに他ならない。
【００７３】
かくして、リクエスタ（C_C）４０６は、自身の秘密キーにより上記一時的ライセンスを解読することにより、当該ファイルＦの内容（S4'）５０５を見ることができる。
【００７４】
医療社会における当事者が非準拠リクエスタを採用することも充分あり得る。このように、上記緊急手順は、好ましくは、これらの非準拠リクエスタも緊急状況では、当該システムの全般的セキュリティを変化させ得ないで、データにアクセスすることができるように適合化されるべきである。提案された解決策は、要求されたデータに対する完全なアクセスを許可する。
【００７５】
この場合、緊急アクセスのログ記録は更に一層重要となる。というのは、これらのリクエスタは、得られたデータを如何なる拘束もなしに開示し得るからである。このような理由で、更なる犯罪捜査追跡のために、透かしを含めることも好ましいであろう。
【００７６】
下記の拡張は、通常（即ち、必ずしも緊急でない）動作の非準拠ピアに対してデータアクセスを付与するために使用することができる。
【００７７】
図６は、緊急状況においてファイルＦ５０１にアクセスする非準拠クライアント（N_C_C）６０１であるリクエスタと、該リクエスタの最寄りの利用可能な緊急エージェント（E_A_E1〜n）４０２〜４０５との間における交換を示す。非準拠クライアント（N_C_C）６０１は、ファイルＦを該ファイルに埋め込まれた緊急ライセンス（S1"）６０２と一緒に緊急エージェント（E_A_E1〜n）４０２〜４０５に送信する。緊急エージェント（E_A_E1〜n）４０２〜４０５は、上記緊急ライセンス（S1"）６０２を解読する、従ってコンテンツキーの内容を回復するために全ての秘密緊急キーについての自身の知識を使用する。このようにして、該緊急エージェントは、ファイルＦを解読し、元のファイルを得ることができる。該緊急アクセスはログ記録され、ファイルＦの解読されたバージョン（S3"）６０４は上記非準拠クライアント（N_C_C）６０１に送信され、該非準拠クライアントは元のファイル（S4"）６０５に自由にアクセスすることができる。
【００７８】
以上、本発明の明確且つ完全な理解を提供するために、開示された実施例の或る特定の詳細が、限定の目的ではなく説明の目的で記載された。しかしながら、当業者によれば、本発明を、本開示の趣旨及び範囲から大幅に逸脱することなしに、ここに記載された詳細とは正確に合致しない他の実施例においても実施することができると理解されるべきである。更に、このような前後状況で、且つ、簡潔化及び明瞭化の目的で、良く知られた装置、回路及び方法の詳細な説明は、不必要な詳細及び可能性のある混乱を回避するために省略されている。
【００７９】
尚、請求項には符号が含まれているが、斯かる符号の挿入は明瞭化のためのみのものであり、斯かる請求項の範囲を限定するものと見なしてはならない。
【技術分野】
【０００１】
本発明は、医療データ（healthcare data）へアクセスするための解読キーを所持し又は該解読キーに対するアクセスを有する信頼されるエージェント（信頼エージェント）により医療データを処理する方法に関する。本発明は、更に、医療データを処理するように構成された信頼エージェントにも関し、該信頼エージェントは医療データにアクセスするための解読キーを所持し又は該解読キーに対するアクセスを有する。本発明は、更に、上記信頼エージェントにより処理される医療データへアクセスするためのリクエストを発生するリクエスト発生器を有するリクエスタ、及び上記信頼エージェントからログを受信するためのレシーバを有するサーバにも関する。
【背景技術】
【０００２】
情報及び通信技術の進歩は、医療分野に大きな利益をもたらすと期待される。相互運用可能な電子健康医療記録（ＥＨＲ）システムの導入は、医療システムの費用を低減すると共に治療の全体的品質を向上させることができる一方、遠隔患者管理（ＲＰＭ）サービスは患者が病院に留まる時間を限られたものにするであろう。それにも拘わらず、現在のところ、ＥＨＲ及びＲＰＭは、むしろ小規模でしか使用されていない。異なるシステムの統合及び手配の問題に関する課題とは別に、情報の保全（セキュリティ）及び私的秘密（プライバシ）に関する不安が、配備されたシステムの不足の主たる理由である。例えば、ＥＨＲシステムは、遵守すべき厳格なセキュリティ及びプライバシ規則（米国におけるＥＵ指令９５／４６又はＨＩＰＡＡ等）に直面している。
【０００３】
近代的医療通信アーキテクチャは、開放された相互接続された環境である傾向がある。機密的患者記録は、最早、医療提供者内で物理的に隔離された、データ及びシステムを防護するために物理的保全手段をとることができるメインフレーム上には存在しない。むしろ、患者のファイルは、家庭医、医療専門家及び非医療提供者さえにも対する分散されたアクセスを可能にするために、データが部分的に信頼のおけないサーバに外部委託され又は斯かるサーバ上で処理されるような環境で保持される。データをデータベースサーバ内に閉じ込め、データに対するアクセスを許可するために伝統的なアクセス制御モデルを使用するような、現在採用されているサーバ中枢的保護モデルは、新しい医療設備の要求に効率的に対処することができない。
【０００４】
異なる医療提供者の間での又は外部当事者との記録の共有を可能にするために、データ中枢的保護を容易にするエンド・ツー・エンド（終端間）保全技術を採用することができる。この場合、データは暗号的に保護され、外部委託され又はネットワーク上を自由に浮遊することさえ可能とされる。秘密性、完全性及び信憑性を提供するために異なるネットワークに依存するというよりは、データは通信の端点で保護される。これは、消費者電子機器のドメインで権利管理技術−デジタル権利管理（ＤＲＭ）を適用し、ビジネスドメインで企業権利管理（ＥＲＭ）を適用することにより達成することができる。このようなシステムでは、公開されるＤＲＭ保護されたデータは暗号化され、ライセンスサーバは、要求するユーザに対して、これらユーザが当該データにアクセスするための充分な権利を有する場合はライセンスを発行する。しかしながら、この技術により解決されない特定の問題は、採用された保護モデルに無関係に、緊急時に電子患者記録に対する即時的アクセスを保証するということである。上記のようなＤＲＭ／ＥＲＭシステムは、全ての必要とされるアクセス権を満たす要求者のみに医療データに対するアクセスを付与することに関しては非常に信頼性があるが、斯様なシステムは、当該システムの通常の動作の免除（例えば、医療提供者が医療データへの即座のアクセスを必要とする場合）を要するような緊急状況に対処することができない。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明の目的は、当該システムの通常の動作の免除を示すと共に、例えば病院等の緊急の医療提供者が、該医療提供者に当該医療データに対するアクセスを許可する通常の権利は存在しないが、該医療データへの即座のアクセスを必要とするような状況に対処することができるという点で、確実であるが同時に柔軟な医療データを処理する方法を提供することにより、上述した欠点を克服することにある。
【課題を解決するための手段】
【０００６】
一態様によれば、本発明は、医療データにアクセスするための解読キーを所持し又は該解読キーに対するアクセスを有する信頼されるエージェント（信頼エージェント）により医療データを処理する方法であって、
【０００７】
医療データへアクセスすることを要求するリクエスタからリクエスタを入力するステップと、
【０００８】
上記リクエスタ又は上記リクエスタ又はこれら両方に関するデータを含むログを発生するステップと、
【０００９】
上記リクエスタに上記医療データへのアクセスを付与するステップと、
を有する方法に関するものである。
【００１０】
このように、如何なる時点においても、上記リクエスタは医療データにアクセスすることができると同時に、該医療データの秘密性を効率的に保護する。当該医療データは暗号化され、上記信頼エージェントは、リクエスタの素性に基づいて、アクセス（解読）が許可されるかを決定することができる。例えば、当該アクセス方針は、医療データは医療提供者によってのみアクセスすることができるとすることができる。更に、アクセスはログ（記録）され、このことは、当該データにアクセスした医療提供者が、自身の行為に責任があるものとさせる。上記信頼エージェントは、例えば、物理的装置又は信頼される供給元からのソフトウェアアプリケーションとすることができ、標準のインターフェースを有することができる。このことは、複数の供給元が実施化を行うのを可能にすると共に、医療アプリケーションが単一のインターフェースを実施化することも要する。
【００１１】
一実施例において、入力された上記リクエストは、該入力されたリクエストが緊急リクエストであることを通知するデータタグを含む。
【００１２】
このように、医療データにアクセスするための緊急リクエストを処理することができないライセンスサーバ、準拠クライアント等が使用されるデジタル権利管理（ＤＲＭ）クライアントアプリケーションのような前述した従来技術のアプリケーションとは異なり、緊急医療者（例えば、病院）は、該医療者がアクセスに対する通常の権利を有していない場合でさえ、該医療者がアクセスしたいデータにアクセスすることを許可するライセンスを許諾される。このような緊急アクセスは、当該医療データのセキュリティの犠牲のもとであり得、斯かるセキュリティは、確かに、重要なフィーチャであるが、それでも患者の安全よりは重要ではない。何故なら、斯様な医療データへの緊急アクセスは患者の生命を救い得るからである。
【００１３】
一実施例において、前記リクエスタから入力されるリクエストは、当該医療データにアクセスするための解読キーの要求を含み、該リクエスタに当該医療データへのアクセスを付与するステップは、要求された解読キーを該リクエスタに送るステップである。
【００１４】
従って、信頼エージェントが、リクエストが入力された全てのクライアントのデータを解読する必要がない場合は、ボトルネックが回避される。斯かる解読は、クライアントアプリケーションで行われる。
【００１５】
一実施例において、前記リクエスタから入力されるリクエストは、暗号化された形態の上記の要求された医療データを含み、該リクエスタに該医療データへのアクセスを付与するステップは、解読された形態の該医療データを該リクエスタに送るステップである。
【００１６】
この構成は、上記信頼エージェントを、デジタル権利管理及びデータ解読をサポートしない旧来のシステムと相互運用するのを可能にする。この場合、前記暗号化されたデータはクライアントアプリケーションにオフラインで記憶される。
【００１７】
一実施例において、入力されたリクエスタに続いて、当該エージェントは暗号化された形態の医療データをサーバから取得すると共に、該医療データを解読し、上記リクエスタに該医療データへのアクセスを付与するステップは、解読された該医療データを上記リクエスタに送るステップである。
【００１８】
この実施例は、先の実施例と同様の利点を提供する。しかしながら、この実施例における上記医療データは中央データベースに記憶される。
【００１９】
一実施例において、当該方法は、前記ログを再吟味のためにサーバに送るステップを更に有する。
【００２０】
このように、前記信頼エージェントは、リクエスト、リクエスタに関する全ての必要な詳細を記録することができる。これは、日付及び時間等の前後関係データ、要求されたデータ等の当該リクエストに含まれる情報、使用されている医療アプリケーション又は装置に対するログイン証明等のリクエスタに関する情報、ＩＰアドレス等の当該装置に関する情報とすることができる。
【００２１】
一実施例において、ライセンスは、当該医療データにアクセスするための解読キー及び関連するライセンス規則を含み、当該リクエスタがデジタル権利管理（ＤＲＭ）クライアントアプリケーション又は企業権利管理（ＥＲＭ）クライアントアプリケーションである場合、斯かるＤＲＭ又はＥＲＭクライアントアプリケーションに当該医療データへのアクセスを付与するステップは、ライセンス解読キー及び関連するライセンス規則を該ＤＲＭ又はＥＲＭクライアントアプリケーションに送るステップである。
【００２２】
一実施例において、当該医療データは文書キー（document key）により保護され、当該ライセンスが、当該保護された医療データに対する緊急キーＫＥｍにより暗号化された文書キーを有する場合、該緊急キーＫＥｍは後に全ての信頼エージェントに分配される。
【００２３】
一実施例において、前記ライセンスは、保護された医療データに付加される。
【００２４】
一実施例において、前記緊急ライセンス及び保護された医療データはＤＲＭ又はＥＲＭに送られ、緊急リクエストの際、斯かるＤＲＭ又はＥＲＭには、文書解読キーを解読するように適合化された緊急キーＫＥｍが更に供給される。
【００２５】
他の態様によれば、本発明は、コンピュータ上で実行された場合に、処理ユニットに上述した方法のステップを実行するように命令するコンピュータプログラムに関するものである。
【００２６】
更に他の態様によれば、本発明は、医療データにアクセスするための解読キーを所持し又は該解読キーに対するアクセスを有し、該医療データを処理するように構成された信頼エージェントであって、
【００２７】
医療データへアクセスすることを要求するリクエスタからリクエストを受信するレシーバと、
【００２８】
上記リクエスト又は上記リクエスタ又はこれら両方に関するデータを含むログを発生するログ発生器と、
【００２９】
受信された上記リクエストを処理し、該処理の結果、前記リクエスタに前記医療データに対するアクセスを付与するプロセッサと、
を有する信頼エージェントに関するものである。
【００３０】
更に他の態様によれば、本発明は、前記信頼エージェントにより処理される医療データにアクセスするためのリクエストを発生するリクエスト発生器を有するリクエスタに関するもので、上記リクエスト発生器は、更に、該発生されたリクエストが緊急リクエストであることを通知するデータタグを発生するように構成される。
【００３１】
更に他の態様によれば、本発明は、前記信頼エージェントからログを受信するレシーバと、該受信されたログを記憶するメモリとを有するサーバであって、
【００３２】
前記メモリは、医療データ、又は医療データにアクセスするための解読キー、又は前記医療データにアクセスするための前記解読キー及び関連するライセンス規則を有するライセンス、又はこれらの組み合わせを更に記憶しており、
【００３３】
信頼される前記サーバは、複数の前記信頼エージェントを操作、供給及び管理し、該操作は、前記信頼エージェントから前記ログを受信することに応答して、斯かる信頼エージェントに要求された解読キーを供給することにより前記医療データに対するアクセスを付与することを含む。
【００３４】
本発明の上記態様の各々は、他の態様の何れとも組み合わせることができる。本発明の、これら及び他の態様は、後述する実施例から明らかとなり、斯かる実施例を参照して説明される。
【図面の簡単な説明】
【００３５】
【図１】図１は、本発明による方法のフローチャートを示す。
【図２】図２は、本発明による信頼エージェント、リクエスタ及びサーバを線図的に示す。
【図３】図３は、ＤＩＣＯＭ（Digital Imaging and Communication in Medicine）に準拠したＤＲＭシステムのための暗号化されたファイル及びライセンスを示す。
【図４】図４は、古いＤＲＭ設備及び新しい緊急設備からなる、緊急アクセスに対するサポートを備える強化されたＤＲＭ設備を示す。
【図５】図５は、準拠クライアントであると見なされ得るリクエスタによる緊急データのアクセスを示す。
【図６】図６は、非準拠クライアントであると見なされ得るリクエスタによる緊急データのアクセスを示す。
【発明を実施するための形態】
【００３６】
以下、本発明の実施例を、図面を参照して例示としてのみ説明する。
【００３７】
図１は、医療データ（healthcare data）にアクセスするための解読キーを所持する又は該解読キーへのアクセスを有する信頼エージェント（trusted agent）により医療データを処理する本発明による方法のフローチャートを示す。該医療データは、患者及び該患者の医療履歴を識別するデータであり得る。上記信頼エージェントは、例えば信頼される製造供給元（vendor）からのソフトウェアアプリケーション又は物理的装置であり得る。好ましくは、信頼エージェントは、複数の製造供給元が実施を行うのを可能にすると共に、医療アプリケーションが単一のインターフェースを実施化するのを要求するような標準インターフェースを有するものとする。上記医療アプリケーションは、通常の医療アプリケーションとして、又は緊急医療アプリケーションとして考えことができる。通常の医療アプリケーションは、保護された医療データにアクセスすることができなければならず、例えばアクセス制御エンジン、デジタル権利管理（ＤＲＭ）クライアント等の方針決定及び執行機能を有する。更に、典型的には、該通常の医療アプリケーションは、結果として保護されたデータに対するアクセスを許可し又は許可しない方針決定及び執行機能となるような証明（credentials）、即ちアイデンティティ、解読キー等を有する。上記信頼エージェントは、上記医療アプリケーションのように必ずしも同一の装置上に配備される必要はないことに注意されたい。
【００３８】
緊急医療アプリケーションは、医療データに対する緊急又は"迅速化された"アクセスが必要な場合である。該緊急医療アプリケーションは、典型的には、保護されたデータへのアクセスを有するが、アクセスを許可する証明は有さない。下記のステップが、斯様な場合を扱う。
【００３９】
ステップ（Ｓ１）１０１において、リクエストがリクエスタ（即ち、この場合は緊急医療アプリケーション）から信頼エージェントに送られるが、該信頼エージェントは、前述したように、当該医療データにアクセスするための解読キーを所持するか又は該解読キーに対するアクセスを有する。受信される上記リクエストは、該受信されたリクエストが緊急リクエスト又は"迅速化される"アクセスのリクエストであることを通知するデータタグを含むことができる。
【００４０】
ステップ（Ｓ２）１０３において、上記信頼エージェントは、上記リクエスト又は上記リクエスタ又はこれら両方に関するデータを含むログ（記録）を発生する。該ログに含まれる情報は、例えば、上記リクエストがなされた日付及び時間等の前後関係データ、要求されたデータのタイプ等の上記リクエストに含まれる情報、例えば当該医療アプリケーションに対するログイン証明又は上記リクエスタ若しくは使用されている装置のＩＤ番号等の上記リクエスタに関する情報、ＩＰアドレス等の当該装置に関する情報等であり得る。
【００４１】
一実施例において、上記ログは、次いで、再吟味のためにサーバ、例えば病院内の中央サーバに送られる（ステップ（Ｓ３）１０５）。
【００４２】
最後に、上記リクエスタに上記医療データに対するアクセスが付与される（ステップ（Ｓ４）１０７）。
【００４３】
一実施例において、前記受信されたリクエストは当該医療データにアクセスするための解読キーの要求を含み、その場合、上記リクエスタに医療データへのアクセスを付与する上記ステップ（Ｓ４）１０７は、要求された解読キーを上記リクエスタに送ることにより実行される。このように、信頼エージェントは、リクエストが受信された全てのクライアントのデータを解読する必要はない。何故なら、解読はクライアントアプリケーションにおいて行われ、障害が回避されるからである。
【００４４】
他の実施例において、上記リクエスタから受信されるリクエストは、暗号化された形態の要求される医療データを含み、前記リクエスタに医療データへのアクセスを付与する前記ステップは、解読された形態の該医療データを上記リクエスタに送るステップを含む。これは、該信頼エージェントを、デジタル権利管理及びデータ解読をサポートしない旧来のシステムと相互運用するのを可能にする。この場合、暗号化されたデータはオフラインでクライアントアプリケーションに記憶される。
【００４５】
一実施例において、前記リクエスタはＤＲＭクライアントアプリケーション又は企業権利管理（ＥＲＭ）クライアントアプリケーションであり、その場合、ライセンスが当該医療データにアクセスするための解読キー及び関連するライセンス規則を有する。該ＤＲＭ又はＥＲＭクライアントアプリケーションに当該医療データへのアクセスを付与する前記ステップは、上記ライセンス解読キー及び関連するライセンス規則を該ＤＲＭ又はＥＲＭクライアントアプリケーションに送るステップを有することができる。これは、後に詳述する。
【００４６】
一実施例においては、前記ログとの交換で新たなキーが獲得される。これは、無制限なアクセスを得るために敵対者によりシステムが"切断され"ないことを保証し、付加的な安全性を提供する。何故なら、上記サーバは、新しく信用できるログ情報を受信した場合にのみ信頼エージェントに緊急キーを分配するからである。
【００４７】
図２は、医療データを処理するように構成されると共に医療データにアクセスするための解読キーを所持し又は該解読キーに対するアクセスを有する信頼エージェント２００、リクエスタ２２０及びサーバ２１０を線図的に示す。
【００４８】
リクエスタ２２０はリクエスト発生器（R_G）２２１を有し、該リクエスト発生器は当該医療データにアクセスするためのリクエスト２２３を発生すると共に、発生されたリクエスト２２３が緊急リクエストであることを通知するデータタグ２２２を更に発生するように構成されている。発生されたリクエスト２２３及びデータタグ２２２は、次いで、通信チャンネル２２４（有線又は無線であり得る）を介して信頼エージェント２００に供給され又は送信される。
【００４９】
信頼エージェント２００は、受信器（Ｒ）２０３、ログ発生器（L_G）２０２及びプロセッサ（Ｐ）２０１を有している。受信器（Ｒ）２０３は、医療データにアクセスすることを要求するリクエスタ２００から上記リクエスト２２３を受信するように構成されている。ログ発生器（L_G）２０２はログ２０４を発生するように構成され、該ログは、先に図１において説明したように、上記リクエスト及び上記リクエスタ又はこれら両方に関するデータを有する。プロセッサ２０１は、受信されたリクエスト２２３を処理するように構成されている。該処理は、サーバ２１０との通信、即ち、例えば医療データにアクセスするための解読キーを要求することによる該サーバとの通信を含む。また、該処理は、要求された解読キーを上記リクエスタに供給する、又は解読された形態の医療データを上記リクエスタに供給することを含む（図１における説明参照）。
【００５０】
ここに図示されたサーバ２１０は通信チャンネル２０５を介して信頼エージェント２００と通信するが、上記通信チャンネルは有線通信チャンネル又は無線通信チャンネルとすることができる。サーバ２１０は、前記ログ２０４を信頼エージェント２００から受信するための受信機（Ｒ）２１１と、受信されたログを記憶するためのメモリ２１２とを有している。該メモリ２１２は、医療データ、又は医療データにアクセスするための解読キー、医療データにアクセスするための関連するライセンス規則を有するライセンス解読キー、又はこれらの組み合わせも記憶している。該サーバは、更に、複数の前記信頼エージェントを操作するように構成され、該操作は、前記信頼エージェントからの前記ログの受信に応答して、該信頼エージェントに、要求された解読キーを供給することにより上記医療データに対するアクセスを付与することを含む。これは、後に詳述する。
【００５１】
図３は、本発明による一実施例を図示し、如何にして本発明をＤＩＣＯＭ（Digital Imaging and Communication in Medicine）に適用することができるかを示している。
【００５２】
ＤＲＭシステムは、医療情報のエンド・ツー・エンド秘密性を保証し、宛先に対する発信元制御を提供する。図３に示されたＤＩＣＯＭファイルのためのＤＲＭシステムは、"National Electric Manufacturers Association (NEMA), Digital Imaging and Communications in Medicine (DICOM), part 15: Security and system management profiles Annex E.1, 2007"（参照により本明細書に組み込まれる）に開示されているような、暗号メッセージ構文及びＤＩＣＯＭ識別不能化プロファイルの緩和バージョンを使用する。このように、保護されなければならないＤＩＣＯＭファイルの属性は、内容暗号化キー（content-encryption key）により暗号化される。次いで、所要のキー材料を持つライセンスが埋め込まれる。これは、規格により提供されるツールが使用されるような方法で実施され、従って、依然として後方互換性を保証する。
【００５３】
セキュリティの観点からは、このＤＲＭ方式は、医療社会の異なるユーザのプライバシ及びデータの分配に対する管理に関しては改善となる。しかしながら、医療セキュリティ解決策が医療専門家により受け入れられるためには、緊急アクセスの可能性を含むことが必須である。
【００５４】
ライセンスサーバ、準拠したクライアント等が使用される医療データ（healthcare data, medical data）に対するＤＲＭ保護を伴う環境を仮定する。公開されるＤＲＭ保護データは暗号化され、ライセンスサーバは、要求するユーザが斯かるデータにアクセスするための充分な権利を有するならば、これらユーザに対してライセンス（内容の使用権を含む）を発行する。従って、緊急アクセスは、該緊急アクセスが当該システムの通常の動作の例外を示すという点で、処理するのが困難である。緊急医療提供者には、好ましくは、該提供者がアクセスしたいデータを解読するライセンスを、該提供者が該データに対する通常の権利を有していなくても許諾されるべきである。従って、このようなアクセスの正当性は、最終的にデータのプライバシを保証するために後に検証されねばならない。この場合、緊急アクセスのログ記録が必要となる。
【００５５】
前述したように、緊急アクセスの管理の課題に対する解決策は、緊急ライセンスを発行し、そのような出来事（イベント）をログ記録することである。これは、ライセンスサーバ２１０（図２参照）により全ての信頼エージェント２００（図２参照）に対し緊急キーＫＥｍを分配することにより実施することができる。内容キーのＫＥｍによる暗号化からなるキーライセンスは、全ての新たに保護される医療データと共に埋め込むことができる。緊急アクセスの際には、信頼エージェント２００は上述したようにイベントをログ記録し、当該リクエスタ（例えば、要求するユーザ）が例えばライセンスサーバから許可を得なかったとしても当該データをＫＥｍにより解読する。
【００５６】
緊急アクセスの管理の課題に対する他の解決策は、ＤＲＭの暗号化時にはデータにライセンスを埋め込まないことである。しかしながら、緊急アクセスの際には、リクエスタ２２０（医療提供者であり得る）は信頼エージェント２００を介して適切なサーバ２１０（例えば、ライセンスサーバ２１０）に接触し、緊急ライセンスを要求する。ライセンスサーバ２１０は、信頼エージェント２００のフィーチャを実施化することができる。即ち、信頼エージェント２００の幾つか又は全てのフィーチャが該ライセンスサーバ２１０に組み込まれていると考えることができるか、又は信頼エージェント２００及びライセンスサーバ２１０が図２に示されたように対話することができる。当該イベントはライセンスサーバによりログ記録され、一時的ライセンスが発行される。
【００５７】
信頼エージェント２００がデータの秘密性を果たすべく緊急状況を処理する責任を負うような図２に示した筋書きは、ＤＲＭシステムと並列に配備することができる。これが図４に示され、該図は古いＤＲＭ設備４１３及び新しい緊急設備４００からなる緊急アクセスのためのサポートを伴う強化されたＤＲＭ設備を示している。
【００５８】
図４は緊急アクセスを備えるＤＲＭ設備がどの様に強化されるかを示しているが、これはＤＩＣＯＭに限られると見なされるべきではなく、種々のシステムが対象である。
【００５９】
新たな緊急設備４００は、図２からの前記サーバ２１０（ここでは、緊急権限者（E_A）４０１と称する）及び複数の前記信頼エージェント２００（ここでは、緊急エージェント（E_A_E1〜n）４０２〜４０５と称する）を有する。緊急権限者E_A）４０１はデータ作成者及び消費者とは独立であり、信頼され得る。最後には、該権限者は緊急アクセスの正当性を検証する責任を負う。該権限者は、この処理をサポートするために幾つかの構成要素を操作する。
【００６０】
緊急エージェント（E_A_E1〜n）４０２〜４０５は、リクエスタ４０６が緊急アクセスを要求する場合に該リクエスタにより接触される。緊急エージェント（E_A_E1〜n）４０２〜４０５は、緊急医療提供者にアクセスを付与し、これらのイベントをログ記録する責任を負う。これらエージェントは、緊急権限者（E_A）４０１により、例えば証明を介して信用される。この目的のために、このような構成者の準拠性は、この信用を仮定する前に、緊急権限者（E_A）４０１（前記サーバ２０１に対応する）によりチェックすることができる。緊急エージェント（E_A_E1〜n）４０２〜４０５は、例えばＤＲＭシステム４１３が配備された病院に設置することができる。
【００６１】
緊急権限者（E_A）４０１は、新たな緊急キーの対ＫprivEm(id)及びＫpubEm(id)を発生するように構成することができる。該緊急権限者は、秘密キーＫprivEm(id)を、好ましくは安全に、該権限者の全ての緊急エージェント（E_A_E1〜n）４０２〜４０５に送信する。緊急権限者（E_A）４０１が、この新たな秘密キーが成功裏に分配されたことを確かめたなら、該権限者は対応する公開キーＫpubEm(id)をライセンスサーバ（L_S_1〜n）４０９〜４１２に、これらサーバが保護されたデータに対する緊急ライセンスを作成することができるように、送信する。
【００６２】
緊急権限者（E_A）４０１による上記キーの発生は、例えば病院毎に１つのキー対、日毎に１つのキー対等の異なる方針に従うことができる。他の代替例として、共通の緊急キーを国内レベルで全てのデータに対して使用することもできる。しかしながら、これらの全てのキーは、接触される緊急エージェント又はファイルとは無関係に、緊急アクセスに際してデータの利用可能性が保証されるように、全ての緊急エージェント（E_A_E1〜n）４０２〜４０５により知られていなければならない。秘密キーＫprivEm(id)が、緊急設備の信頼される環境内に留まることが重要である。開示された秘密キーに基づく緊急ライセンスを含む全てのＤＲＭにより保護されたデータの秘密性は、言い換えれば、危うくされる。
【００６３】
ＤＲＭ発行者（Publ.）による元のファイルＦの暗号化に際して、緊急ライセンスLFEmが、結果としてのファイルに埋め込まれる。該ライセンスは、当該ＤＲＭ保護ファイルに対して責任のあるライセンスサーバにより、緊急公開キーＫpubEm(id)についての知識を用いて作成される。結果的な暗号化されたＤＲＭコンテナは、上記元のデータを暗号化された形態で含む。
【００６４】
リクエスタ（例えば、緊急医療提供者）が、自身が既にダウンロードしたファイルＦに対する緊急のアクセスを必要とする場合、該リクエスタは好ましくは最寄りの利用可能な緊急エージェント（E_A_E1〜n）４０２〜４０５に接触する。
【００６５】
図４に示された実施例は、ＤＩＣＯＭに焦点を当てたものである。従って、交換メッセージは、新たなＤＩＣＯＭ緊急アクセスサービスオブジェクト対（ＳＯＰ）クラスとして定義される。
【００６６】
一般的に、ＤＩＣＯＭは、サービスオブジェクト対（ＳＯＰ）クラスにおける情報オブジェクト定義（ＩＯＤ）に適用可能なサービスの組を定義する。ＳＯＰクラスは、正規化された又は複合のＩＯＤに当てはまるかに依存して、正規化されたもの又は複合のものの何れかとなり得る。正規化されたＩＯＤは、一般的に実社会のＤＩＣＯＭモデルにおける単一のエンティティを表す情報オブジェクト定義である。複合ＩＯＤは、実社会のＤＩＣＯＭモデルに含まれる幾つかのエンティティの部分を表す情報オブジェクト定義である。ＳＯＰクラスは、固有の識別子、即ちＳＯＰクラスＵＩＤ、により識別される。ＳＯＰクラス内のサービスが既述されるためには、先ず、参加者の各々に役割を割り当てる必要がある。ピアは、サービスクラスユーザ（ＳＣＵ：即ちクライアント）若しくはサービスクラス提供者（ＳＣＰ：即ちサーバ）の何れかであり得るか、又は両方の役割を同時になす。サービス記述は、当該ＩＯＤに適用され得るコマンドも定義する。既存のコマンド型式は、C-STORE、C-FIND、C-MOVE、C-GET、C-CANCEL及びC-ECHOを含む。
【００６７】
１つのＤＩＣＯＭノードから他のものへコマンドが送られる場合、このコマンドは該コマンドに関わるＳＯＰクラス及びＩＯＤインスタンスに対する参照を含み、追加のデータ集合を添付することができる（当該コマンドのペイロード）。宛先は、コマンド実行ステータス（例えば、失敗、成功等）及びオプションとしての添付ペイロードにより回答する可能性を有する。２つのアプリケーション（アプリケーションエンティティ）が通信したいと欲する場合、これらアプリケーションは、何のサービス（ＳＯＰクラス）を使用としているかについて合意しなければならない。従って、通信確立手順は、連合交渉（association negotiation）と呼ばれるサポートされるＳＯＰクラスの交渉を含む。通信するアプリケーションエンティティのうちの一方が、或るＳＯＰクラスをサポートしない場合、関連するサポートは使用することができない。
【００６８】
ＤＩＣＯＭファイルに方針を含めるために、暗号化された属性データセット（即ち、ＣＭＳエンベロープ）がＤＩＣＯＭファイルに埋め込まれる。新たな属性、即ち開示キー、も導入される。該キーは、属性を保護するために使用されるであろう対称キーを含む。暗号化に際して、下記の処理が生じる。
保護されねばならない全ての属性は、開示キーのキーを含め、スクランブルされる。
当該属性の暗号化されたバージョンを含むＣＭＳエンベロープが、開示キーのものは除き、作成される。該エンベロープの文書暗号化キーは、元の開示キー属性のキーを用いて暗号化される。
ユーザが当該データにアクセスすることを要求した場合、前記ライセンスサーバは、元の開示キー属性を含む、ＤＩＣＯＭ規格に準拠した新たなＣＭＳエンベロープを発生する。該エンベロープの文書暗号化キーは、準拠するクライアント又はユーザの公開キーを用いて暗号化される。
【００６９】
新たなライセンスの作成に際して、流布されるＤＩＣＯＭコンテンツは変更されない。即ち、ライセンスは後の使用のために当該ファイルに添付され得るのみである。前記方針は、ＣＭＳエンベロープ内に保護されない属性として保存される。従って、異なるユーザに対して異なる方針を設定することができる。この解決策は、異なる属性を保護する全てのエンベロープが異なる方針仕様を有することができるという意味で、非常に柔軟なものでもある。
【００７０】
図５はプロトコルを線図的に示し、該図において、準拠クライアント（C_C）４０６と見なすことができるリクエスタ４０６は、ファイルＦ５０１に対するアクセスを、該Ｆに埋め込まれた緊急ライセンス（S1'）５０２を緊急エージェント（E_A_E1〜n）４０２〜４０５に送ることにより要求する。ＤＩＣＯＭでは、これは、上記緊急ライセンスを含むN-ACTIONコマンドとして実施化することができる。前述したように、緊急エージェント（E_A_E1〜n）４０２〜４０５なる用語は、単に図２に示されたような信頼エージェント２１０の一実施例である。また、前述したように、緊急権限者（E_A）４０１は１以上の緊急エージェント（E_A_E1〜n）４０２〜４０５を操作することができ、該緊急エージェントは、なかでも、リクエスタ４０６によるリクエストに応答して前記ログ処理を実行する。
【００７１】
図５に示したプロトコルを再び参照して、上記リクエスタ（C_C）４０６が確かに準拠クライアントであることをチェックした後、該リクエスタ（C_C）４０６に対するログ（S2'）５０３が発生される。緊急権限者（E_A）４０１（図５には図示せず）は、受信された緊急ライセンスを適切な秘密キーを用いて解読する。内容キー（コンテンツキー）を回復した後、上記リクエスタの公開キーを用いて、該リクエスタ（C_C）４０６によってのみ使用されることを意図する新たな一時的ライセンスが構築される。
【００７２】
次いで、新たな一時的ライセンス（S3'）５０４は、リクエスタ（C_C）４０６に送られる。ＤＩＣＯＭでは、これは、上記一時的ライセンスを含むN-EVENT-REPORTコマンドとして実施化することができ、従って、該ライセンスは図３に示したようなＤＩＣＯＭライセンスに他ならない。
【００７３】
かくして、リクエスタ（C_C）４０６は、自身の秘密キーにより上記一時的ライセンスを解読することにより、当該ファイルＦの内容（S4'）５０５を見ることができる。
【００７４】
医療社会における当事者が非準拠リクエスタを採用することも充分あり得る。このように、上記緊急手順は、好ましくは、これらの非準拠リクエスタも緊急状況では、当該システムの全般的セキュリティを変化させ得ないで、データにアクセスすることができるように適合化されるべきである。提案された解決策は、要求されたデータに対する完全なアクセスを許可する。
【００７５】
この場合、緊急アクセスのログ記録は更に一層重要となる。というのは、これらのリクエスタは、得られたデータを如何なる拘束もなしに開示し得るからである。このような理由で、更なる犯罪捜査追跡のために、透かしを含めることも好ましいであろう。
【００７６】
下記の拡張は、通常（即ち、必ずしも緊急でない）動作の非準拠ピアに対してデータアクセスを付与するために使用することができる。
【００７７】
図６は、緊急状況においてファイルＦ５０１にアクセスする非準拠クライアント（N_C_C）６０１であるリクエスタと、該リクエスタの最寄りの利用可能な緊急エージェント（E_A_E1〜n）４０２〜４０５との間における交換を示す。非準拠クライアント（N_C_C）６０１は、ファイルＦを該ファイルに埋め込まれた緊急ライセンス（S1"）６０２と一緒に緊急エージェント（E_A_E1〜n）４０２〜４０５に送信する。緊急エージェント（E_A_E1〜n）４０２〜４０５は、上記緊急ライセンス（S1"）６０２を解読する、従ってコンテンツキーの内容を回復するために全ての秘密緊急キーについての自身の知識を使用する。このようにして、該緊急エージェントは、ファイルＦを解読し、元のファイルを得ることができる。該緊急アクセスはログ記録され、ファイルＦの解読されたバージョン（S3"）６０４は上記非準拠クライアント（N_C_C）６０１に送信され、該非準拠クライアントは元のファイル（S4"）６０５に自由にアクセスすることができる。
【００７８】
以上、本発明の明確且つ完全な理解を提供するために、開示された実施例の或る特定の詳細が、限定の目的ではなく説明の目的で記載された。しかしながら、当業者によれば、本発明を、本開示の趣旨及び範囲から大幅に逸脱することなしに、ここに記載された詳細とは正確に合致しない他の実施例においても実施することができると理解されるべきである。更に、このような前後状況で、且つ、簡潔化及び明瞭化の目的で、良く知られた装置、回路及び方法の詳細な説明は、不必要な詳細及び可能性のある混乱を回避するために省略されている。
【００７９】
尚、請求項には符号が含まれているが、斯かる符号の挿入は明瞭化のためのみのものであり、斯かる請求項の範囲を限定するものと見なしてはならない。
【特許請求の範囲】
【請求項１】
医療データにアクセスするための解読キーを所持するか又は該解読キーに対するアクセスを有する信頼エージェントにより医療データを処理する方法であって、
医療データにアクセスすることを要求するリクエスタからリクエストを受信するステップと、
前記リクエスト又は前記リクエスタ又はこれら両方に関するデータを有するログを発生するステップと、
前記リクエスタに前記医療データへのアクセスを付与するステップと、
を有する方法。
【請求項２】
前記受信されたリクエストが、該受信されたリクエストが緊急リクエスタであることを通知するデータタグを有する請求項１に記載の方法。
【請求項３】
前記リクエスタから受信された前記リクエストが前記医療データにアクセスするための解読キーを要求すること含み、前記リクエスタに前記医療データへのアクセスを付与するステップが、前記要求された解読キーを前記リクエスタに供給するステップである請求項１に記載の方法。
【請求項４】
前記リクエスタから受信された前記リクエストが、暗号化された形態の前記要求された医療データを含み、前記リクエスタに前記医療データへのアクセスを付与するステップが、解読された形態の前記医療データを前記リクエスタに供給するステップである請求項１に記載の方法。
【請求項５】
前記受信されたリクエストに続いて、前記エージェントは暗号化された形態の前記医療データをサーバから取得すると共に該医療データを解読し、前記リクエスタに前記医療データへのアクセスを付与するステップが、前記解読された医療データを前記リクエスタに供給するステップである請求項１に記載の方法。
【請求項６】
前記ログを再吟味のためにサーバへ供給するステップを更に有する請求項１に記載の方法。
【請求項７】
ライセンスが前記解読キーを、前記医療データへアクセスするための関連するライセンス規則と共に有し、前記リクエスタがデジタル権利管理（ＤＲＭ）クライアントアプリケーション又は企業権利管理（ＥＲＭ）クライアントアプリケーションであり、前記ＤＲＭ又はＥＲＭクライアントアプリケーションに前記医療データへのアクセスを付与するステップが、前記ライセンス解読キーを、関連するライセンス規則と共に前記ＤＲＭ又はＥＲＭクライアントアプリケーションに供給するステップである請求項１に記載の方法。
【請求項８】
前記医療データが文書キーにより保護され、前記ライセンスが、該保護された医療データに対する緊急キーＫＥｍにより暗号化された前記文書キーを有し、該緊急キーＫＥｍが次いで全信頼エージェントに分配される請求項７に記載の方法。
【請求項９】
前記ライセンスが前記保護された医療データに添付される請求項８に記載の方法。
【請求項１０】
前記緊急ライセンス及び前記保護された医療データが前記ＤＲＭ又はＥＲＭに供給され、緊急リクエストに際して、前記ＤＲＭ又はＥＲＭに、前記文書解読キーを解読する緊急キーＫＥｍが更に供給される請求項８に記載の方法。
【請求項１１】
コンピュータ上で実行された場合に、処理ユニットに請求項１に記載の方法のステップを実行するように命令するコンピュータプログラム。
【請求項１２】
医療データにアクセスするための解読キーを所持するか又は該解読キーに対するアクセスを有し、前記医療データを処理する信頼エージェントであって、
医療データにアクセスすることを要求するリクエスタからリクエストを受信するためのレシーバと、
前記リクエスト又は前記リクエスタ又はこれら両方に関するデータを有するログを発生するためのログ発生器と、
前記受信されたリクエストを処理し、該処理の結果、前記リクエスタに前記医療データへのアクセスを付与することになるプロセッサと、
を有する信頼エージェント。
【請求項１３】
請求項１２に記載の信頼エージェントにより処理される医療データにアクセスするためのリクエストを発生するリクエスト発生器を有し、該リクエスト発生器が、前記発生されたリクエストが緊急リクエストであることを通知するデータタグを更に発生するリクエスタ。
【請求項１４】
請求項１２に記載の信頼エージェントからログを受信するレシーバと、該受信されたログを記憶するメモリとを有するサーバであって、
前記メモリは、医療データ、又は医療データにアクセスするための解読キー、又は医療データにアクセスするための関連するライセンス規則を有するライセンス解読キー、又はこれらの組み合わせを更に記憶しており、
前記サーバは複数の前記信頼エージェントを操作、供給及び管理し、前記操作が、前記信頼エージェントから前記ログを受信することに応答して、該信頼エージェントに、要求された解読キーを供給することにより前記医療データに対するアクセスを付与することを含むサーバ。
【請求項１】
医療データにアクセスするための解読キーを所持するか又は該解読キーに対するアクセスを有する信頼エージェントにより医療データを処理する方法であって、
医療データにアクセスすることを要求するリクエスタからリクエストを受信するステップと、
前記リクエスト又は前記リクエスタ又はこれら両方に関するデータを有するログを発生するステップと、
前記リクエスタに前記医療データへのアクセスを付与するステップと、
を有する方法。
【請求項２】
前記受信されたリクエストが、該受信されたリクエストが緊急リクエスタであることを通知するデータタグを有する請求項１に記載の方法。
【請求項３】
前記リクエスタから受信された前記リクエストが前記医療データにアクセスするための解読キーを要求すること含み、前記リクエスタに前記医療データへのアクセスを付与するステップが、前記要求された解読キーを前記リクエスタに供給するステップである請求項１に記載の方法。
【請求項４】
前記リクエスタから受信された前記リクエストが、暗号化された形態の前記要求された医療データを含み、前記リクエスタに前記医療データへのアクセスを付与するステップが、解読された形態の前記医療データを前記リクエスタに供給するステップである請求項１に記載の方法。
【請求項５】
前記受信されたリクエストに続いて、前記エージェントは暗号化された形態の前記医療データをサーバから取得すると共に該医療データを解読し、前記リクエスタに前記医療データへのアクセスを付与するステップが、前記解読された医療データを前記リクエスタに供給するステップである請求項１に記載の方法。
【請求項６】
前記ログを再吟味のためにサーバへ供給するステップを更に有する請求項１に記載の方法。
【請求項７】
ライセンスが前記解読キーを、前記医療データへアクセスするための関連するライセンス規則と共に有し、前記リクエスタがデジタル権利管理（ＤＲＭ）クライアントアプリケーション又は企業権利管理（ＥＲＭ）クライアントアプリケーションであり、前記ＤＲＭ又はＥＲＭクライアントアプリケーションに前記医療データへのアクセスを付与するステップが、前記ライセンス解読キーを、関連するライセンス規則と共に前記ＤＲＭ又はＥＲＭクライアントアプリケーションに供給するステップである請求項１に記載の方法。
【請求項８】
前記医療データが文書キーにより保護され、前記ライセンスが、該保護された医療データに対する緊急キーＫＥｍにより暗号化された前記文書キーを有し、該緊急キーＫＥｍが次いで全信頼エージェントに分配される請求項７に記載の方法。
【請求項９】
前記ライセンスが前記保護された医療データに添付される請求項８に記載の方法。
【請求項１０】
前記緊急ライセンス及び前記保護された医療データが前記ＤＲＭ又はＥＲＭに供給され、緊急リクエストに際して、前記ＤＲＭ又はＥＲＭに、前記文書解読キーを解読する緊急キーＫＥｍが更に供給される請求項８に記載の方法。
【請求項１１】
コンピュータ上で実行された場合に、処理ユニットに請求項１に記載の方法のステップを実行するように命令するコンピュータプログラム。
【請求項１２】
医療データにアクセスするための解読キーを所持するか又は該解読キーに対するアクセスを有し、前記医療データを処理する信頼エージェントであって、
医療データにアクセスすることを要求するリクエスタからリクエストを受信するためのレシーバと、
前記リクエスト又は前記リクエスタ又はこれら両方に関するデータを有するログを発生するためのログ発生器と、
前記受信されたリクエストを処理し、該処理の結果、前記リクエスタに前記医療データへのアクセスを付与することになるプロセッサと、
を有する信頼エージェント。
【請求項１３】
請求項１２に記載の信頼エージェントにより処理される医療データにアクセスするためのリクエストを発生するリクエスト発生器を有し、該リクエスト発生器が、前記発生されたリクエストが緊急リクエストであることを通知するデータタグを更に発生するリクエスタ。
【請求項１４】
請求項１２に記載の信頼エージェントからログを受信するレシーバと、該受信されたログを記憶するメモリとを有するサーバであって、
前記メモリは、医療データ、又は医療データにアクセスするための解読キー、又は医療データにアクセスするための関連するライセンス規則を有するライセンス解読キー、又はこれらの組み合わせを更に記憶しており、
前記サーバは複数の前記信頼エージェントを操作、供給及び管理し、前記操作が、前記信頼エージェントから前記ログを受信することに応答して、該信頼エージェントに、要求された解読キーを供給することにより前記医療データに対するアクセスを付与することを含むサーバ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公表番号】特表２０１１−５２４５６４（Ｐ２０１１−５２４５６４Ａ）
【公表日】平成２３年９月１日（２０１１．９．１）
【国際特許分類】
【出願番号】特願２０１１−５１２２５３（Ｐ２０１１−５１２２５３）
【出願日】平成２１年５月２９日（２００９．５．２９）
【国際出願番号】ＰＣＴ／ＩＢ２００９／０５２２６３
【国際公開番号】ＷＯ２００９／１４７５９８
【国際公開日】平成２１年１２月１０日（２００９．１２．１０）
【出願人】（５９００００２４８）コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ (12,071)
【Ｆターム（参考）】
【公表日】平成２３年９月１日（２０１１．９．１）
【国際特許分類】
【出願日】平成２１年５月２９日（２００９．５．２９）
【国際出願番号】ＰＣＴ／ＩＢ２００９／０５２２６３
【国際公開番号】ＷＯ２００９／１４７５９８
【国際公開日】平成２１年１２月１０日（２００９．１２．１０）
【出願人】（５９００００２４８）コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ (12,071)
【Ｆターム（参考）】
[ Back to top ]