(57)【要約】  ユーザインタフェース及びそのユーザインタフェースに結合されるプロセッサであって、当該プロセッサは、前記ユーザインタフェースを通してアクセス要求を受信し、前記ユーザインタフェースを通してアクセスを許可する。プロセッサは、アクセス権を決定するために、権利要求と役割ベースポリシーとを関連付けて、特定のユーザ及び記録に関する例外リストに従って、決定されたアクセス権を修正し、修正され決定されたアクセス権に基づいて、記録へのアクセスを許可する。同じ例外がユーザ又は記録の過半数に適用される場合には、役割ベースポリシーがその例外を含むように修正する。
2009525516.tif 000002
【特許請求の範囲】
【請求項１】
記録保持システム中の保護されたリソースへのアクセス権を制御するための役割ベースアクセス制御（RBAC）システムを使用する方法であって、
アクセス権を決定するために権利要求を役割ベースポリシーに関連付け、
特定のユーザ及び記録に関連する例外リストに従って、決定されたアクセス権を修正し、並びに
決定され修正されたアクセス権に基づいて、記録へのアクセスを許可する、方法。
【請求項２】
前記役割ベースポリシーが、個別ポリシーとして修正されたデフォルトポリシーである、請求項１に記載の方法。
【請求項３】
例外がユーザ及び記録の少なくとも一方の過半数に適用されるかを決定し、並びに
前記例外がユーザ及び記録の少なくとも一方の過半数に適用される場合、前記例外を含むように前記役割ベースポリシーを修正し、
以前は前記役割ベースポリシーによって制御されていた少数のユーザ権に適用されるように前記例外リストを修正する、請求項１に記載の方法。
【請求項４】
前記役割ベースポリシーを前記例外リストに関連付ける、請求項１に記載の方法。
【請求項５】
前記例外リストが複数の例外リストのうちの1つであり、当該方法は、複数の役割ベースポリシーの各々を前記複数の例外リストのうちの1つ以上に関連付ける、請求項１に記載の方法。
【請求項６】
前記役割ベースポリシーが複数の役割ベースポリシーのうちの１つであり、前記例外リストが複数の例外リストのうちの１つであり、当該方法は、前記複数の役割ベースポリシーの各々１つを、前記複数の例外リストのうちの１つに関連付ける、請求項１に記載の方法。
【請求項７】
追加のアクセス権及び制限されるアクセス権を前記例外リストに関連付ける、請求項１に記載の方法。
【請求項８】
保護されたリソースへのアクセスを制御するための役割ベースアクセス制御（RBAC）システムであって、
ユーザインタフェース、及び前記ユーザインタフェースに動作可能に結合されるプロセッサを有し、
前記プロセッサは、前記ユーザインタフェースを通してアクセス要求を受信し、前記ユーザインタフェースを通してアクセスを許可し、
前記プロセッサは、アクセス権を決定するために権利要求を役割ベースポリシーに関連付け、特定のユーザ及び記録に関する例外リストに従って、決定されたアクセス権を修正し、及び決定され修正されたアクセス権に基づいて記録へのアクセスを許可する、システム。
【請求項９】
前記プロセッサが、例外がユーザの過半数に適用されるかを決定し、前記例外がユーザの過半数に適用される場合に前記例外を含むように前記役割ベースポリシーを修正し、以前は前記役割ベースポリシーによって制御されていた少数のユーザ権に適用されるように前記例外リストを修正する、請求項８に記載のシステム。
【請求項１０】
前記役割ベースポリシーが複数の役割ベースポリシーのうちの１つであり、前記例外リストが複数の例外リストのうちの１つであり、前記プロセッサが、前記複数の役割ベースポリシーのうちの各々１つを前記複数の例外リストのうちの１つに関連付ける、請求項８に記載のシステム。
【請求項１１】
前記プロセッサが、追加のアクセス権及び制限されるアクセス権を前記例外リストに関連付ける、請求項８に記載のシステム。
【請求項１２】
前記プロセッサが、前記役割ベースポリシーを前記例外リストに結合することによって前記役割ベースポリシーを決定するための命令を更新する、請求項８に記載のシステム。
【請求項１３】
役割ベースアクセス制御システム（RBAC）を提供するように計算機可読媒体上に組み入れられたアプリケーションであって、
アクセス権を決定するために、権利要求を役割ベースポリシーに関連付ける部分、
特定のユーザ及び記録に関連する例外リストに従って、決定されたアクセス権を修正する部分、並びに
決定され修正されたアクセス権に基づいて記録へのアクセスを許可する部分、を有するアプリケーション。
【請求項１４】
前記役割ベースポリシーが、個別ポリシーとして修正されたデフォルトポリシーである、請求項１３に記載のアプリケーション。
【請求項１５】
例外がユーザ及び記録の少なくとも一方の過半数に適用されるかを決定する部分、
前記例外がユーザ及び記録の少なくとも一方の過半数に適用される場合、前記例外を含むように前記役割ベースポリシーを修正する部分、並びに
以前は前記役割ベースポリシーによって制御されていたユーザ権及び記録のうちの少なくとも一方の少数に適用されるように前記例外リストを修正する部分、を有する請求項１３に記載のアプリケーション。
【請求項１６】
前記役割ベースポリシーを前記例外リストに関連付ける部分を有する、請求項１３に記載のアプリケーション。
【請求項１７】
前記例外リストが複数の例外リストのうちの１つであり、当該アプリケーションは、複数の役割ベースポリシーの各々を前記複数の例外リストのうちの１つ以上に関連付ける部分を有する、請求項１３に記載のアプリケーション。
【請求項１８】
前記役割ベースポリシーが複数の役割ベースポリシーのうちの１つであり、前記例外リストが複数の例外リストのうちの１つであり、当該アプリケーションは、前記複数の役割ベースポリシーの各々１つを前記複数の例外リストのうちの１つに関連付ける部分を有する、請求項１３に記載のアプリケーション。
【請求項１９】
追加のアクセス権及び制限されるアクセス権を前記例外リストに関連付ける部分を有する、請求項１３に記載のアプリケーション。
【請求項２０】
例外が同じポリシーを持つアトミックブロックの過半数に適用されるかを決定する部分、
前記例外が前記アトミックブロックの過半数に適用される場合に、前記例外を含むように前記役割ベースポリシーを修正する部分、及び
以前は前記役割ベースポリシーによって制御されていた少数のアトミックブロックに適用されるように前記例外リストを修正する部分を有する、請求項１３に記載のアプリケーション。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願人は、2005年9月16日に出願された仮出願番号60/718,180の利益を請求する。
【０００２】
本システム（個別役割ベースアクセス制御モデル（Personalized Role-Based Access Control Model：PRBAC））は、改善された役割ベースアクセス制御モデルに関する。
【背景技術】
【０００３】
データセキュリティ及びプライバシー問題は、医療分野において伝統的に重要である。しかしながら、医療記録のデジタル化のような最近の発展、中央健康記録データベースの作成、及びパーソナルヘルスケア分野における院外アプリケーション（例えば保険会社によるアクセス）は、医療データの保護に対して新たな課題を提起する。システムの不正使用の損失を吸収することができる金融分野のような他の分野とは対照的に、ヘルスケアは吸収できない。一旦、個人の健康問題に関するセンシティブな情報が暴露され、社会的な損害が発生すると、情報を撤回し、又は個人に補償する方法はない。
【０００４】
さらに、医療情報データは、例えば一般開業医、救急医師、看護婦などの、医療分野内で特定の役割を割り当てられる許可された人によってのみ、医療データがアクセス可能でなければならないというような、いくつかの特殊な特性を持つ。これは、アクセスが一般的に一対一ベースで提供される典型的なデータ保証システムとは異なる。
【０００５】
そのような要求をサポートするために、アクセス制御システムが各々のユーザに所与の役割を割り当てる一方で、データにアクセスする許可は、個人ではなく、その所与の役割に割り当てられる。そのようにして、医師及び患者の電子健康記録（EHR）へのアクセスを必要としている他の人々は、その人が特定の時間に仕えているそれらの専門（役割）又は特定の機能に依存した異なる権利及び異なるアクセスを与えられる。役割ベースアクセス制御（Role Based Access Control：RBAC）と呼ばれるこのアプローチは、それが実務で便宜のために用いられていることに加えて、それが同様にヘルスケア分野において法律（例えばHIPAA (HEALTH INSURANCE PORTABILITY AND ACCOUNTABILITY ACT OF 1996））によって米国で強制されるので、ヘルスケア分野において非常に重要である（hipaa.orgのインターネット上のHIPAAを参照のこと）。
【０００６】
2004年5月20日付Fleming等による米国特許公開番号2004/0098594、発明の名称"System and Method for Creating Role-Based Access Profiles"は、組織内のコンピュータリソースのための既存のアクセスグループに関する情報から、そのようなプロファイルを生成する方法を開示する。動作中に、データを保護する当事者は提携者のリストにアクセスして、アクセス権をモデル化するためにリストから提携者の選択を行う。この刊行物は、全体として引用したものとする。しかしながら、この方法において患者入力は考慮されておらず、したがって、アクセス権は患者の個々の要求に合わせて調整されることができない。
【０００７】
Griffin等による2002年11月28日付の米国特許公開番号2002/0178119、発明の名称"Method and System for a Role-Based Access Control Model with Active Roles"は、役割フィルタ及び権限フィルタを用いた動的な更新を含むことによってリソースへのアクセスを管理するためのRBAC方法及びシステムを開示する。各々の役割フィルタは、どのユーザがその役割であるかについて決定するために評価される。各々の役割フィルタは、アクセス権限、アクセス条件権利及びそれらの権利の資格をさらに含む。この刊行物は、全体として引用したものとする。この方法においても、患者入力は考慮されておらず、したがって、アクセス権は患者の個々の要求に合わせて調整されることができない。
【０００８】
2000年2月8日にKuhnに対して発行された米国特許番号6,023,765、発明の名称"Implementation of Role-Based Access Control in Multi-Level Secure Systems"は、RBACシステムに関する権利とマルチレベルセキュリティシステム内のレベル及び区画の対との間の関係を確立する方法を開示する。この特許は、ジョブステータスなどに基づいて、米国政府において用いられているような３つの分類レベルを持つ分類された書類へのアクセスを制御することを目的とする。ユーザ主体は、ユーザがアクセスを許可された役割のメンバであることに基づいてその主体が分類された書類にアクセスすることを許可されていることを承認する信用された仲介者を通してアクセスの要求を行う。この刊行物は、全体として引用したものとする。上記のリファレンスの問題と同様に、主体はこのシステムに関するアクセス権を調整する能力を与えられない。
【０００９】
2005年9月20日にGullotta等に発行された米国特許6,947,989、発明の名称"System and Method for Provisioning Resources to Users Based on Policies, Roles, Organization Information, and, Attributes"は、リソースをユーザに供給するための手段を開示する。この方法は、属性、組織的情報、ユーザ役割、並びに属性及びユーザ役割に基づいたリソース供給ポリシーを使用する。この方法によって、ユーザは、コンピュータ及び電話のようなハードリソース並びにデータベース、ファイル、フォルダなどへのアクセスのようなソフトリソースを含む特定のリソースを与えられる。他のユーザや定義された組織的役割以外の人にデータベースへのアクセスを制限することのようなこのプロセスをユーザが制御することを可能にする用意はない。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
したがって、患者によって指示されて調整されることができるアクセス制御を考慮する個別役割ベースアクセス制御システムの必要性が存在する。
【００１１】
パーソナルユーザに焦点を当てたヘルスケアに向けたヘルスケア分野における最近の傾向は、同様に、ヘルスケアの全ての段階において更なるユーザ（例えば患者）の関与を要求する。最近では、患者は、疾患情報を取得し、問題について医師と議論し、症状を追跡し、及び彼らの病気を管理することによって、彼ら自身のヘルスケア管理において、より能動的な役割を担っている。結果的に、患者はまた、彼らがアクセスした重要な医療書類を保持して管理することにさらに関与し、同様に、他人のアクセスを制限することを要求する。
【００１２】
電子ヘルスケア記録にアクセスする能力は、HIPPA Act（患者は、HIPPA Actによって、患者個人の健康記録へのアクセスに関する制限を要求する権利を持つ）を制定した法律制定者による注意を引き起こした。例えば患者は、彼らの治療に関与する特定の個人への彼らの記録の開示に関する更なる制限を要求することができ、その特定の個人は、さもなければ（治療機関によって管理される役割ベースアクセス制御に関して）アクセスを許可される。治療提供者は、その要求に同意することを必要とされない。しかしながら、治療提供者が同意する場合には、（例えば緊急時に患者を治療するために情報が必要とされる場合のような特定の場合を除き）その合意に従うことが必要とされる。
【００１３】
これは、健康記録に対する守秘性及びアクセス制御に関する更なる要求を提起する。すなわち、いくつかの場合には、アクセスは役割に基づき、他の場合には、役割だけでなく個々の制限にも基づく。さらに、患者は、個人の記録へのアクセスを拡張することができなければならず、そして特定の家族又は友人にアクセスを許可することができなければならない。したがって、役割ベースアクセス制御と患者によって管理されたアクセス制御の組み合わせが明らかに必要である。
【００１４】
今日では、財産権的情報の保護に対するソリューションは、主に静的RBACモデルに基づく。現行の法律を考慮したヘルスケア産業は、フレキシビリティ及び承認規則を含む、より多くを必要とする。
【００１５】
従来技術のこれらの及び他の不都合を克服することが本システムの目的である。
【課題を解決するための手段】
【００１６】
本システムは、ヘルスケア産業を対象とし、ヘルスケアアプリケーション及び電子医療記録の機密保護を対象とする法律の機密保護要求を満たすように効率的に例外を取り扱うことができる改善された役割ベースアクセス制御システム及び方法を提供する。
【００１７】
本システムは、ポリシーリポジトリ（Policy Repository）及び例外リストを含む。最初に、ポリシーリポジトリは、役割に基づいてシステムによって定義されるデフォルトポリシーを含む。患者はその後、権利を制限し又は権利を追加することによって例外を作成することができ、それにより個別ポリシー（Personalized Policy）が定義され、ポリシーリポジトリに追加される。システムは通常、デフォルトポリシーのセットを持つが、それらが個別ポリシーによって変更される場合、これらの個別ポリシーはデフォルトポリシーに優先し、デフォルトポリシーはリポジトリ中で適切に置き換えられる。
【００１８】
この状況における個別ポリシーは、古い個別ポリシーが新たな個別ポリシーによって無効にされることができるという点で、動的である。例外リストは、デフォルトポリシー又はデフォルトポリシーに優先する個別ポリシー（それぞれその時点の個別ポリシー）に抵触する全ユーザのリストとして定義されることができる現行の個別ポリシーとして機能する。一実施例において、例外リストは、ブラックリストとホワイトリストの融合として機能することができ、例えば、コンピュータ資産に対する要件並びにアクセスを取得する際の時間及び医療データへの適切なアクセスを保証するのを助ける際の時間を低減するために使用されることができる。
【００１９】
本システムのこれらの及び多くの他の目的、特徴及び利点は、本システムの好ましい実施の形態の以下の詳細な説明及び関連する図面から、当業者にとって容易に明らかとなる。
【００２０】
図面は説明の便宜上含まれており、本システムの範囲を示さないことが明確に理解される。本システムは、添付の図面を参照して、一例として、さらに詳細に説明される。
【発明を実施するための最良の形態】
【００２１】
本システムは、ヘルスケア分野の医療記録に関して本願明細書において実例として説明される。当業者にとって直ちに明らかであるように、本システムは、任意の種類の電子記録保持システム内の任意の種類の記録へのアクセスを制限することに適切に適用されることができる。
【００２２】
本システムの範囲内に、２つのタイプのユーザが一般に存在する。第１のタイプのユーザは、ヘルスケア提供者（例えば病院）のデフォルトポリシーによって定義されるアクセス規則に対する追加又は修正/操作を含む、記録へのアクセス制御規則を定義する権利を持つユーザである。ヘルスケア分野において、これは記録が適用される患者ユーザである。患者ユーザは、その患者ユーザのヘルスケア記録へのアクセス権を定義し又は修正することができ、したがって、要望どおりにアクセスを許可又は制限することができる。第２のタイプのユーザは、患者ユーザによって定義される権利に従って記録にアクセスするユーザである。実例として、異なるユーザが論じられる際の区別を容易にするために、用語「患者ユーザ」及び「ヘルスケアユーザ」などが本願明細書において利用される。
【００２３】
本システムの実施の形態に従って、ポリシーリポジトリ及び例外リストは、記録に対するヘルスケアユーザのアクセスを制御するために利用されることができる。最初に、ポリシーリポジトリは、役割に基づいてシステムによって定義されるデフォルトポリシー（DP）を含むことができる。DPはそれによって、記録の特定の分類と、記録へのアクセスを要求する可能性がある潜在的なヘルスケアユーザの役割との間の関係を定義する。デフォルトポリシーは、アクセスポリシーを作成するようにデータのアトミックブロック（atomic block）を結合することによって一般に定義される。アトミックブロックは、完全に実行するか又は全く実行しないように見える最小のXACML（eXtensible Access Control Markup Language）要素として定義される。アトミックブロックは論理ユニットとして存在する。例えば、デフォルトポリシー（DP）は、患者のEmployee Health Record（EHR）への一般開業医（GP）のアクセスに関することができる。
実例となるDPは、
「DP：GPは任意の患者の全てのEHRにアクセスする」
である。
他の実施例として、外科専門家（SP）は、GPよりも制限された権利を持つ場合がある。実例となるSPのためのDPは、
「DP：SPは任意の患者の全ての外科的なEHRにアクセスする」
である。
【００２４】
このようにして、単にデフォルトの役割ベースアクセス制御（RBAC）だけによって、異なる医療専門家は、特定の医療専門分野にとって重要であるEHRの分類へのアクセスを潜在的に提供される。
【００２５】
本システムに従って、患者はその後、ポリシーリポジトリに追加されてデフォルトポリシーの代わりに個別ポリシーを作成した患者に少なくとも適用される個別ポリシーを作成するために、権利を制限し又は権利を追加することによって例外を作成することができる。このようにして、本システムは、個別ポリシーによって変更されることができるデフォルトポリシーのセットを持つ。これらの個別ポリシーはデフォルトポリシーに優先し、少なくとも所与の個別ポリシーを作成した患者のための患者記録へのアクセスを制御するようにポリシーリポジトリ中で適切に設定される。
【００２６】
個別ポリシーは一般に、デフォルトポリシーと同様であり、個別ポリシーを作成するためにアトミックブロックをデフォルトポリシーから除去し若しくはデフォルトポリシーにアトミックブロックを追加することによって除去され若しくは追加されることができるヘルスケアユーザの役割又はコンテントの分類を定義する。ユーザは、デフォルトポリシーから始めて、アトミックブロックレベル又は記録レベルで単に制限を除去又は追加することによって個別ポリシーを作成することができる。例えば、ポリシーリポジトリ中で個別ポリシー（PP）によって置き換えられるデフォルトポリシー（DP）は、
「DP：GPは患者のEHRにアクセスする」
「ユーザAのPP：GPは婦人科のEHR以外の患者のEHRにアクセスする」
である。
【００２７】
このシステムは、個別ポリシーによって修正されるように、RBACに基いて記録へのアクセスを制御する簡易な方法を提供する。さらに、患者が新たな個別ポリシーによって古い個別ポリシーを無効にすることを決定することができるという点で、この状況における個別ポリシーは動的であることができる。個別ポリシーが特定の患者のために作成される場合において、新たな個別ポリシーは、単にポリシーリポジトリ中の古い個別ポリシーを置き換えることができる。個別ポリシーが患者のグループに適用される場合、特定の患者に適用される新たな個別ポリシーは、ポリシーリポジトリに単に追加されることができ、そして新たな個別ポリシーを作成した患者に適用されることができる。
【００２８】
個別ポリシーが作成される場合、これらのポリシーは優勢であり、少なくとも個別ポリシーを作成した患者又は個別ポリシーが適用される患者のグループのためのデフォルトのポリシーを無効にする。要するに、個別ポリシーは、少なくとも個別ポリシーを作成した患者又は個別ポリシーが適用される患者のグループのためのデフォルトポリシーになる。
【００２９】
更なる実施の形態によれば、ヘルスケアユーザのための例外リスト（EL）は、デフォルトポリシー又は定義されている場合は現行の個別ポリシーに抵触する全てのヘルスケアユーザ又は役割のリストとして定義されることができる。例外リストがより少ない又はより多くの権利を与える場合、コンフリクトが存在する可能性がある。"+"は、ヘルスケアユーザが追加の権利を持つことを示すために使用されることができ、"-"は、ヘルスケアユーザが制限された権利を持つことを示すために使用されることができる。例外リストは、例外リスト中に存在するヘルスケアユーザに対して、いくつかの権利を授け、又は無効にする。
【００３０】
本システムの実施の形態によれば、２つのアルゴリズムが、上に述べたようにシステムを作動させるために使用されることができる。第１のアルゴリズム（CreatePersonalizedPolicy）は、患者が例外リストを作成するときに利用されることができる。更なる実施例では、CreatePersonalizedPolicyアルゴリズムはまた、個別ポリシーによってデフォルトポリシーを置き換えることが望ましいかどうかを決定することができる。この実施例において、例外リストに存在する同じ制限又は追加の権利が、半分よりも多くのヘルスケアユーザに関わる場合、デフォルトポリシー又は現行の個別ポリシーは、それぞれ個別ポリシー又は新たな個別ポリシーによって無効にされることができる。動作中に、一旦例外リストがユーザによって作成されると、CreatePersonalizedPolicyアルゴリズムは、同じ例外の下のヘルスケアユーザの数が過半数であるかを考慮することができる。同じ例外の下のヘルスケアユーザの数が過半数である場合、これは、例外がほとんど一般的なものであり、アルゴリズムが、デフォルトポリシー又は古い個別ポリシーをその同じ例外とそれぞれ結合することによって、個別ポリシーを定義又は修正することができることを意味する。
【００３１】
動作中に、ヘルスケアユーザが患者記録を要求する場合、第２のアルゴリズム（RequestRights）は最初にデフォルトポリシーをチェックすることができる。RequestRightsアルゴリズムは、それから、個別ポリシー又は少なくとも適用可能な個別ポリシーがその記録及びヘルスケアユーザのために存在するかどうかをチェックすることができる。最後に、RequestRightsアルゴリズムは、例外リスト中のヘルスケアユーザの存在を探すことができる。RequestRightsアルゴリズムは、ヘルスケアユーザの権利を戻す。
【００３２】
識別名アンナ、バート、チャールズ、ダニエル及びエマによって識別される５人の特定の一般開業医（GP）のための本システムの実施の形態の実例を示す。フランクは、これらのGPが勤務する病院の患者である。この例では、フランクは、一部の医療記録を恥じており、フランクが個人的に知っているGP（すなわち、チャールズ）に対して性病に関する彼の電子健康記録の部分へのアクセスを認めないことを決定する。全てのアクセス権（ポリシー）がアトミックブロックとして定義されるので、フランクは、フランクの性病に関するアトミックブロックへのアクセスを制限することができる。実例として、フランクの性病に関するアトミックブロックは、ブロック17及び18である。フランクに対するアクセスは、
「DP：    GPは患者のEHRにアクセスする」
「PP：    NULL（フランクはPPを持たない）」
「EL：    GP(チャールズ, -17/-18）)
のようになる。
【００３３】
この例をさらに詳しく説明すると、フランクは、いくらかの考慮の後、このデータへのアクセスをチャールズだけでなく、彼を治療したGP、すなわちバートを除く全てのGPにも同様に制限することを決定する。個別ポリシーが存在しないとすると、例外リストはこのようになる。
「DP：    GPは患者のEHRにアクセスする」
「PP：    NULL」
「EL：    GP(チャールズ, -17/-18）
GP(アンナ, -17/-18）
GP(ダニエル, -17/-18）
GP(エマ, -17/-18）)
【００３４】
しかしながら、本システムの実施の形態によれば、上記のアクセス制御表現は、
「DP：    GPは患者のEHRにアクセスする」
「PP：    GPは、ブロック17及び18を除き、患者のEHRにアクセスする」
「EL：    GP(バート, +17/+18）)
と簡素化することができる。
【００３５】
この実施例において、個別ポリシーが、ここでは（実際には）デフォルトで、デフォルトポリシーに優先することができるので、バート以外のGPはブロック17及び18にアクセスしない。このようにして、例外リストは、４つではなく１つの要素だけを持つように、非常に単純化されることができる。
【００３６】
さらに他の実施の形態において、個別ポリシーは、先の例における17及び18のような異なるデータブロック又はデータブロックのグループに関連した複数のアトミックポリシーブロックから、上述のように構成されることができる。全てのアトミックポリシーブロックに適用される１つの例外リストを持つ代わりに、これらのブロックの各々は、このブロックに関する別の例外リストと関連することもできる。
【００３７】
患者のデータを要求している特定の役割によって識別されるヘルスケアユーザの権利を知ることが必要なときはいつでも、個別ポリシーは問い合わせられることができる。本システムの実施の形態によれば、役割ポリシーは、例外リストをできる限り軽く（小さく）維持するために修正されることができる。この実施例による例では、管理者（即ち患者）が同じ例外を新たなヘルスケアユーザに適用することを決定するときに、ちょうど半分のユーザが同じ例外を持つと仮定する。この追加される例外によって、過半数がこの例外（制限）による影響を受ける。この実施の形態によれば、例外リスト中に過半数のユーザを持つことを回避するために、デフォルトポリシーに共通の例外/制限を加えたものと同じである新たな個別ポリシーが、作成されることができる。例外リストは、一旦更新されると、特定の役割に従事しながらアクセス制限又は追加の権利を持つ少数のヘルスケアユーザを含む。例外リスト中の各々のラインは、１人のヘルスケアユーザに関係することができ、役割、ヘルスケアユーザのＩＤ又は関連するヘルスケアユーザを識別する他の手段、並びに患者の１人及び１つ以上のアトミックブロックに関するヘルスケアユーザが持つ制限又は追加の権利を含むことができる。新たな個別ポリシーが作成されるときに、影響を受ける役割を持つヘルスケアユーザの全ての権利及び制限が更新される。
【００３８】
実施の形態が、１人の患者及びその患者の記録へのアクセスを制限しているポリシーに大いに関連してこれを論じたが、更なる実施の形態は、同じポリシー（デフォルトポリシー又は個別ポリシーのいずれか）を持つように患者をグループ化することを含むことができる。このようにして、患者のアクセスポリシーは、彼らの個別ポリシー及び例外リストの関数として、結合されることができる。
【００３９】
図1は、様々な患者が同じ個別ポリシー（いくつかの場合にはNULL）及び同じ例外リストを持つこの実施の形態による実例となる例である。もちろん、各々の患者は、図示されていないが、同じデフォルトポリシーを共有する。図1において、患者P1, P2, PMは同じ個別ポリシーλ及び例外リストλを共有し、患者P3は個別ポリシーθ及び例外リストθを持ち、そして、患者PNは、個別ポリシーξ及び例外リストξを持つ。
【００４０】
図2は、患者が同じ個別ポリシーと異なる例外リストを持つ更なる実施の形態による実例となる例である。図2において、患者P1, P2, PMは同じ個別ポリシーλを共有するが、各々は患者固有の例外リスト持つ。患者P3とPNは各々、別々の個別ポリシー（それぞれθ及びξ）並びに別々の例外リストを持つ。
【００４１】
図3は、実例として上記した本システムの実施の形態の１つ以上に従って機能することができるシステム300を示す。このシステムは、患者がポリシー及び例外リストを作成することを容易にするユーザインタフェース310をホストする表示装置350を含む。ユーザインタフェース310はまた、ポリシー及び例外に従ってヘルスケアユーザが記録へのアクセスを要求することを容易にする。表示装置350は、使用可能な状態で、単独で又は表示装置350の機能と共に、ユーザインタフェース310の生成を容易にするように構成されるプロセッサ330に結合される。プロセッサ330は同様に、ポリシー、例外及びアクセス要求に関する命令を受信するように動作可能である。メモリ340は、使用可能な状態でプロセッサ330に結合され、上述のような動作のためにプロセッサによって実行される動作命令のような、必要な命令及びデータを記憶することが可能である。メモリ340は同様に、ユーザインタフェース310及びプロセッサ330を通して患者及びヘルスケアユーザによってアクセスされることができるポリシー、例外及び記録を記憶するように動作可能である。プロセッサ330及びメモリ340は全体として、サーバベース記録アクセスシステム320として機能する。表示装置350、プロセッサ330及びメモリ340の間の相互接続は、例えば有線若しくは無線通信で直接的に又はネットワークを通して、任意の通信リンクを介することができることに留意すべきである。インターネット又はイントラネットリンクのような有線通信であるようなメモリ340とプロセッサ330との間と同様に、Bluetooth（登録商標）通信プロトコルを使用するような短距離無線通信も、例えばプロセッサ330と表示装置350との間では、適している。
【００４２】
ワイヤ又は無線インタフェースを通して信号を送受信するためのトランシーバも必要に応じて提供されることができ、無線通信の場合にはアンテナを含む。変調器、復調器及びフィルタも、情報又は制御信号を更なる処理のためにキャリア信号から抽出するために使用されることができる。
【００４３】
プロセッサ330は、マイクロプロセッサ、マイクロコントローラ、縮小命令セットコントローラ、及びユーザインタフェース310からの入力信号に応答して制御信号を提供して、（任意の種類のメモリ、RAM、ROM、リムーバブルメモリ、光メディア、電磁メディア等であることができる）メモリ340中に記憶される命令を実行することができる他の装置を含む、電子信号を処理するための任意の種類のコントローラ又はプロセッサであることができる。表示装置350、プロセッサ330及びメモリ340は、システム300の一部として示されるが、単独の又は他のユニットと結合した別々のユニットであることができることが理解されるべきである。例えば、プロセッサ330及びメモリ340は、パーソナルコンピュータの一部であることができ、ユーザ表示装置350は、それとは別のユニット、又はそこに組み込まれたユニットであることができる。表示装置自体は、パーソナルコンピュータにおいて、又はユーザインタフェース310のホストをして、ユーザ入力を受け取り、パーソナル携帯情報機器（PDA）、携帯電話などのようなプロセッサ330に制御信号を提供することが可能な任意の装置において実現されることができる。
【００４４】
添付の図面を参照して本システムの実施の形態を説明したが、本システムは厳密な実施の形態に制限されず、様々な変更や修正が、添付の請求の範囲において定められる範囲又は精神から逸脱することなく、当業者によって遂行され得ることが理解されるべきである。
【００４５】
添付の請求の範囲を解釈する際は、以下の点が理解されるべきである。
a) 「有する，含む」との語は、所与の請求項中に挙げられたもの以外の他の要素又は行為の存在を除外しない。
b) 単数形の要素は、そのような要素が複数存在することを除外しない。
c) 請求項中の任意の参照符号は、その範囲を制限しない。
d) いくつかの「手段」は、同じアイテム、又はハードウェア若しくはソフトウェアによって実現された構造若しくは機能により代表されることができる。
e) 任意の開示された要素は、(例えば、個別的な電子回路及び集積化された電子回路を含む）ハードウェア部分、ソフトウェア部分（例えばコンピュータプログラミング）、及びそれらの任意の組み合わせから成ることができる。
f) ハードウェア部分は、アナログ部分及びデジタル部分の一方又は両方から成ることができる。
g) 任意の開示された装置又はその部分は、特に述べられない限り、一体に結合され、又は更なる部分に分離されることができる。
h) 特に示されない限り、行為又はステップの特定の順序が必要なことは意図されない。
【図面の簡単な説明】
【００４６】
【図１】患者が、本システムの実施の形態による類似の個別ポリシー及び例外リストを持つモデルを示す図。
【図２】患者が、本システムの実施の形態による類似の個別ポリシーと異なる例外リストを持つモデルを示す図。
【図３】本システムの実施の形態による個別役割ベースアクセス制御システムのブロック図。
【図１】
2009525516.tif 000003
【図２】
2009525516.tif 000004
【図３】
2009525516.tif 000005
【国際調査報告】
2009525516.tif 000006
2009525516.tif 000007