/

ISO 13606-4:2019 健康情報学—電子健康記録通信—パート4：セキュリティ | ページ 3

※一部、英文及び仏文を自動翻訳した日本語訳を使用しています。

導入

0.1 一般

この文書は、ウィーン協定を通じて CEN と ISO が共同で発行した 5 部構成の標準シリーズの一部です。このドキュメントでは、このシリーズの他の部分への依存関係が適用されるwhere 明示的に述べられています。

0.2 この文書が取り組む課題

電子医療記録 (EHR) の全体または一部を、組織内および組織の境界を超えて、場合によっては国境を越えて通信することは、セキュリティの観点から困難です。医療記録は、内容の機密性と患者による使用方法の正当な管理を保証する方法で作成、処理、管理される必要があります。世界中で、これらの原則が国のデータ保護法に徐々に盛り込まれつつあります。これらの文書は、治療対象者が電子医療記録の内容と配布に関する決定において重要な役割を果たす権利と、その内容について知らされる権利を有することを宣言します。医療記録情報の第三者への伝達は、患者の同意がある場合にのみ行われるべきです（これは、データ主体が自分に関する個人データに対する同意を示す、患者の希望を具体的かつ十分な情報に基づいて示すものでありえます）加工済み）。詳細については、ISO 22600-3 を参照してください。 ISO 22857 は、国境を越えた EHR コミュニケーションについて、適切なセキュリティ ポリシー仕様を定義するために使用できるガイダンスを提供します。

理想的には、患者の記録内のきめ細かい各エントリには、その情報を閲覧する権限を持ち、患者によって指定または承認され、患者に対する正当な注意義務を負う一連の人の動的な性質を反映している人だけがアクセスできるようにすべきです。彼または彼女の生涯を通して。アクセス制御リストには、理想的には、注意義務以外の理由 (医療サービス管理、疫学と公衆衛生、同意された研究など) でデータにアクセスする許可を持つ人々も含めますが、アクセスする必要のない情報は除外します。患者がアクセスするには個人的すぎると感じるものを参照してください。逆に、患者またはその代理人が情報を個人的またはプライベートなものとしてラベル付けすることは、緊急時に正当にその情報を見る必要がある人々を妨げたり、真の医療提供者が誤って自分たちのようなフィルターをかけられた視点を持つことになったりすることが理想的にあってはならない。誤解されて患者を不適切に管理した。患者の個人的な健康不安が年齢を重ねたり、健康問題に対する社会の態度が変化したりするにつれて、健康記録の記載内容の固有の感受性1に対する患者の見解は、時間の経過とともに変化する可能性があります。患者は、家族、友人、介護者、コミュニティのメンバーに対して、さまざまなレベルのアクセスを提供したいと考えるかもしれません。家族は、家系図内の遺伝性疾患の進行を監視するために、互いの記録の一部に（必ずしも同じ範囲にアクセスできるわけではない）アクセスできる手段を提供したいと考えるかもしれません。

このような一連の要件は、おそらく、他のほとんどの業界部門のデータ管理者に求められる要件よりも広範囲にわたります。実際には、次のような理由で非常に複雑になります。

  • 現代の医療の過程で患者に対して行われる多数の健康記録の入力。
  • 多数の医療従事者が配置を交代することが多く、いつでも患者と接触する可能性がある。
  • 患者が生涯にわたって接触する可能性のある多数の組織。
  • 記録エントリの機密性を標準化された方法で分類することの難しさ（患者にとっても他の人にとっても）。
  • 単一の医療記録エントリが患者の将来のケアにとって、またどのクラスのユーザーにとってどれほど重要であるかを判断することの難しさ。
  • EHR の論理的に削除できない性質と、EHR エントリ自体の改訂と同じ方法でアクセス許可の改訂を厳密に管理する必要性。
  • 適切なアクセスを非常に迅速に、リアルタイムで、場合によっては分散コンピューティング環境で決定する必要性。
  • 開示に対する同意を記録し尊重してもらうことに対して、少数派の患者が表明する高い懸念。
  • 大多数の患者がこれらの要件について抱いている懸念のレベルは低いため、歴史的に、EHR コミュニケーションのこの側面に取り組むための優先順位と投資が限られてきました。

相互運用可能な EHR, および医療提供者間の EHR データのシームレスな通信をサポートするには、EHR データの特定の要求者にデータの受信を許可するかどうかを決定するために必要なネゴシエーションが自動化できる必要があります。これが不可能な場合、すべてまたはほとんどの記録通信に対する人間の決定を管理するための遅延と作業負荷が発生し、データの相互運用性を目指す努力の価値がなくなってしまいます。

EHR 通信アクセス制御の分野における標準開発へのアプローチの主な原則は、リクエストの特性とパラメータを EHR プロバイダーのポリシー、および指定された EHR 内のアクセス制御または同意宣言に一致させ、維持することです。開示の適切な証拠を作成し、これを自動処理できるようにします。実際には、コンピュータ間のネゴシエーションが可能なアクセス制御および特権管理システムを定義するための国際標準を開発する取り組みが進行中です。ただし、この種の作業は、医療サービスがスタッフに割り当てたい権限と、EHR 内で定義するために患者に提供する機密性の範囲を定義するための相互に一貫した枠組みに同意することを前提としています。これには、定義時 (新しい EHR エントリが追加されるとき)、実行時 (EHR 全体が取得またはクエリされるとき) で賢明にスケーラブルであり、長期にわたる耐久性を実現するために、関連情報の表現方法に一貫性が必要です。患者の一生。また、当分の間は、法律の違いを含め、EHR 通信を保護する具体的なアプローチに関して各国間に多様性が存在し続けること、標準化に対する高度に規範的なアプローチは現在不可能であることを認識することも重要です。

したがって、この文書ではアクセス ルール自体を規定するものではありません。誰が何に、どのセキュリティメカニズムを使用してアクセスできるのかは指定されていません。これらは、ユーザー コミュニティ、国のガイドライン、法律によって決定される必要があります。ただし、EHR アクセス ポリシーの最小仕様として使用できる基本フレームワークと、よりきめの細かい詳細なポリシー情報を伝達するためのより豊富な汎用表現を定義します。このフレームワークは、ISO 13606-1 で定義された全体的なアーキテクチャを補完し、ISO 13606-1 で定義された EHR_EXTRACT の一部として通信される特定の情報構造を定義します。 EHR 通信のセキュリティに必要な種類の合意の一部は、必然的にこの文書の範囲外となり、ISO 22600 (特権管理とアクセス制御) でより広範囲にカバーされます。

相互運用可能な情報セキュリティ展開の全体的な整合性を図るために、この文書と並行して他の標準を使用する場合には、明示的および暗黙的な依存関係が数多く存在することに注意してください。適切な規格の全範囲についての合意に加えて、関連する保証制度も必要となります (これはこの文書の範囲を超えています)

0.3 通信シナリオ

0.3.1 データの流れ

EHR 通信をサポートするために必要なインターフェイスとメッセージ モデルは、ISO 13606-5 の主題です。ここでの説明は、セキュリティ機能が必要な対話を示すための通信プロセスの概要です。図 1 は、このドキュメントで考慮する必要がある主要なデータ フローとシナリオを示しています。主要なデータ フローごとに確認応答があり、オプションで、要求されたデータの代わりに拒否が返される場合があります。

図 1 —この文書で取り上げる主なデータ フローとセキュリティ関連のビジネス プロセス

EHR 要求者、EHR 受信者、および監査ログのレビュー者は、医療専門家、患者、法定代理人、または医療情報にアクセスする十分な権限を持つ別の当事者である可能性があります。 EHR_EXTRACT と監査ログ (提供されている場合) の両方をフィルタリングして、受信者の権限に一致する開示を制限する必要がある場合があります。アクセス制御のこの側面については、この概要の後半で説明します (EHR プロバイダーだけでなく、ここに示されているすべての関係者が監査ログを維持する必要があります。ただし、読みやすくするために、他の監査ログ プロセスについてはここでは図示または説明されていません)

次の節では、図 1 の各データ フローについて説明します。

0.3.2 EHR データのリクエスト

この対話は常に必要なわけではありません (たとえば、退院概要の場合のように、EHR データがプロバイダーから受信者にプッシュされる場合があります) EHR プロバイダーがアクセスの決定を行い、監査ログにデータを入力し、目的の受信者に適切なデータを提供できるようにするために、要求インターフェイスには要求者の十分なプロファイルが含まれている必要があります。場合によっては、EHR 要求者が EHR 受信者と同じ当事者ではない場合があります。たとえば、ソフトウェア エージェントが、医療専門家に送信される EHR データを含む通知をトリガーする場合があります。このような場合、アクセスの決定を決定するのは主に EHR 受信者の資格情報です。

EHR リクエストには、たとえば患者からの何らかの形式の明示的な同意やケア義務を提供することによって、アクセスに対する同意やケア義務を含めたり、参照したりする必要がある場合があります。

EHR データのリクエスタとプロバイダ間のネゴシエーションはますます自動化されており、この対話に含まれる情報は、完全にコンピュータ化されたポリシー ネゴシエーションを可能にするのに十分なものでなければなりません。

この対話の要件は、ISO 13606-5 で定義されている REQUEST_EHR_EXTRACT インターフェイス モデルに反映されます。

0.3.3 EHR アクセス ログ エントリの生成

これはどの EHR システムでも実践されていると想定されていますが、現在のシステムではアプローチや機能が多様であるため、規範的なインターフェイスとしては指定されていません。 EHR システム内の内部監査システムは、この文書の第 8 項で定義されたモデルおよび ISO 13606-5 で定義された対応するインターフェイスのサポートを除き、相互運用可能である必要はありません。

0.3.4 EHR リクエストの受信確認

医療固有のセキュリティに関する考慮事項はありません。

0.3.5 アクセスの決定、EHR データのフィルタリング

EHR リクエストを処理するときは、ターゲット EHR からどのデータを抽出するかを決定する際に、EHR プロバイダーに関連するポリシーと EHR 自体のアクセス ポリシーをすべて考慮する必要があります。この文書は、EHR プロバイダーに影響を与える可能性のある一連のポリシー全体を規定するものではなく、国、地域、組織固有、専門職およびその他の法律に由来する可能性があります。

EHR データの機密性と、EHR 要求者と受信者の特権に基づいて EHR データをフィルタリングする決定は、関連するポリシーに準拠する必要があり、情報へのアクセスを拒否する臨床リスクと情報を公開する医学法的リスクのバランスを取る必要がある場合があります。情報。

ただし、この文書は、患者または代表者によって承認された特定の EHR に関連するアクセス ポリシーを相互運用可能な方法で表現するための全体的なフレームワークを定義します。これらは、この方法では物理的な EHR システムに保存されない場合があります。代わりに、たとえば、EHR サーバーにリンクされたポリシー サーバー内に統合することもできます。

このアクセスの決定については、第 7 条で詳しく説明します。

0.3.6 EHR_EXTRACT の提供を拒否する

アクセスの決定が拒否される場合、EHR プロバイダーからの適切な応答のセットを構成するために、大まかな理由のセットを定義する必要があります。ただし、拒否およびその理由が、要求された EHR データが存在することを受信者に示唆するものではないことが重要です。データの存在を開示すること自体が患者に損害を与える可能性があります。

医療固有のセキュリティに関する考慮事項はありません。インターフェイス モデルは ISO 13606-5 で定義されています。

0.3.7 EHR_EXTRACT を提供する

EHR 受信者は EHR 要求者と同じである必要はなく、実際、EHR の提供は要求によってトリガーされる必要はないことに注意してください。代わりに、共有ケア経路の一部として、または既存の EHR に新しいデータを追加するために、プロバイダーによって開始された可能性があります。

EHR_EXTRACT は、ISO 13606-1 で定義された参照モデルおよび ISO 13606-5 で定義されたインターフェイス モデルに準拠する必要があります。

EHR_EXTRACT には、通信される EHR データの後続の伝播を管理するために、この文書に従って表現された関連するアクセス ポリシーが含まれるか参照されます。ポリシーは、EHR 受信者が別の手段で同じ情報に直接アクセスできることがわかっている場合にのみ参照できます。

0.3.8 EHR_EXTRACT の受信確認

医療固有のセキュリティに関する考慮事項はありません。

0.3.9 EHR アクセス ログ エントリの生成

0.3.3 で説明されているとおりです。

0.3.10 EHR アクセス ログ表示のリクエスト

これは現在、情報共有環境で誰が自分の EHR の一部またはすべてにアクセスしたかを患者が発見できるようにするため、望ましい実践であると考えられています。このドキュメントで定義されているこのインターフェイスの範囲は、特定の EHR システム内で誰が自分の EHR のどの部分にいつアクセスしたかを受信者に知らせる監査ログの表示を要求することです。このインターフェイスは、法的目的またはその他の調査のために監査ログの完全な検査が必要where 状況をサポートすることを目的としていません。このインターフェースについては第 6 項で説明します。

インターフェイス モデルは ISO 13606-5 で定義されています。

0.3.11 EHR アクセス ログ エントリの生成

0.3.3 で説明されているとおりです。

0.3.12 EHR アクセス ログ ビューの提供

これは実際に望ましいことであり、そのようなエントリ (またはエントリのセット) の相互運用可能な表現が必要です。このインターフェースについては第 6 項で説明します。

法的調査では、監査ログが完全かつ修正されていない形式で提供されることが必要ですが、監査ログ ビューを患者または医療専門家に提示するには、一部のエントリ（EHR データに言及するエントリなど）をフィルタリングして除外する必要がある場合があります。患者はアクセスできません）。

インターフェイス モデルは ISO 13606-5 で定義されています。

0.3.13 EHR アクセスログ表示の拒否

要求が満たされない場合は、大まかな理由を定義する必要があります。ただし、拒否およびその理由が、要求された EHR データが存在することを受信者に示唆するものではないことが重要です。データの存在を開示すること自体が患者に損害を与える可能性があります。

医療固有のセキュリティに関する考慮事項はありません。インターフェイス モデルは ISO 13606-5 で定義されています。

0.3.14 EHR アクセス ログ ビューの受信確認

医療固有のセキュリティに関する考慮事項はありません。

0.3.15 EHR アクセス ログ エントリの生成

0.3.3 で説明されているとおりです。

0.4 要件と技術的アプローチ

0.4.1 一般的な医療セキュリティ要件

機密データや個人データを扱うドメインにおける全体的なセキュリティ アプローチに関して最も広く受け入れられている要件は、ISO/IEC 27002 で公開されています。これは、EHR データなどの資産を保護するために講じるべき対策の種類と、そのようなデータがどのように保護されるかを指定しています。分散コンピューティング環境の一部として安全に通信できるようになります。この一般規格の健康に特化したガイドは、ISO 27799 (健康情報学 – ISO/IEC 27002 を使用した健康におけるセキュリティ管理) で発行されています。これにより、医療全体にわたる共通のセキュリティ ポリシーの策定が容易になり、相互運用可能なセキュリティ コンポーネントおよびサービスの導入促進に役立つはずです。 ISO 22600 (医療情報学 - 特権管理とアクセス制御) は、そのようなポリシーを正式かつ一貫して定義および管理するための包括的なアーキテクチャ アプローチを定義しています。国境を越えた EHR コミュニケーションに関して、ISO 22857 は、適切なセキュリティ ポリシー仕様を定義するために使用できるガイダンスを提供します。

特定の EHR 通信インスタンスを許可するために満たす必要がある正確なセキュリティ要件は、送信サイトと受信サイトの両方、および通信チェーン内の中間リンクにおける多くの国および地方のポリシーによって管理されます。これらのポリシーの多くは医療コミュニケーション全般に​​適用され、この文書で指示できない、また指示すべきではない方法で国や臨床現場によって異なります。したがって、この文書の草案で採用されたアプローチは、一般的なセキュリティ ポリシー、コンポーネント、およびサービスが、EHR 抽出の通信を許可する前の交渉段階 (アクセス決定) に寄与し、実際の EHR データ フローを保護すると仮定することでした。

したがって、この文書では、ISO 27799 に準拠する全体的なセキュリティ ポリシーまたは一連のポリシーが、EHR コミュニケーションに参加するすべてのサイトで導入されていること、また、これらのポリシーが国内または国境を越えたデータ保護法に準拠していることを要求しています。 EHR データの通信または使用に適用される特定の国、地方、専門家、または組織の規制に準拠するために、追加のポリシーが必要になる場合があります。このようなポリシーの定義については、このドキュメントの範囲を超えています。

0.4.2 他の関連セキュリティ規格との関係

EHR データへの正当なアクセスは、広範囲のポリシーによって決定され、その一部はドキュメントとして存在し、一部はアプリケーション内でエンコードされ、一部は正式な認証システム コンポーネント内で存在する可能性があります。ベンダーや組織によって、アクセス制御ポリシーやサービスの実装方法、およびそれらが現在どの程度コンピュータ化されているかが異なることが認識されています。

ISO 22600 (すべての部分) は、プリンシパル (エンティティ) の特権、潜在的なターゲット オブジェクトに関連するアクセス コントロール ポリシー、およびアクセスの決定に達するために必要なネゴシエーション プロセスを表現するための汎用論理モデルを定義します。図 2 は、ISO 22600 で定義されている役割ベースのアクセス制御の概念を示しています (すべての部分)

図 2 —役割ベースのアクセス制御 [ISO 22600 (全部分)] で定義されている主な概念とポリシーの種類

ISO 22600 (すべての部分) に従って、ロール、プロセス、ターゲット オブジェクト、および関連する権限に対する制約をポリシーによって定義すると、図 2 が図 3 に変わります。

図 3 —ポリシー主導の RBAC スキーム

図 3 に示すように、プリンシパル (個人、エージェントなど) は 1 つ以上の機能的役割にマッピングされ、その機能的役割は、プリンシパルが保持することを許可されている構造的役割の影響を受けます。たとえば、医学的資格を持ち、小児医療の専門家である人は、1 つ以上の構造上の役割 (病院の小児科コンサルタント、地域の小児検査責任者など) を兼任する場合があります。これらの構造的役割により、彼または彼女は患者に対して個人臨床医の機能的役割を担うことができる場合があります。機能的役割は永続的である場合もあれば、単一のユーザー セッションに限定されている場合もあります。機能的役割は、特定の操作 (EHR への新しいエントリの書き込みなど) を実行する権限と、特定のオブジェクト (役割保持者が表示を許可されている EHR データなど) にマップされます。

このドキュメントの目的上、図 3 に示す Target_Component クラスは、EHR プロバイダーが保持する EHR データです。 Permission_Assignment 関連付けは、EHR の一部またはすべてへのアクセスを許可または拒否するポリシーを定義します。これは、その後の採用と伝播のために EHR 受信者に通知する必要もあります。この文書はその標準の採用を前提としていますが、国の運用構造と用語は異なり、差異が生じる可能性があることを認識しています。ただし、この文書では、実際のアクセス ポリシーを相互運用可能な方法で伝達するためのフレームワークとしてポリシー モデルを指定するだけです。それ自体は、管轄区域またはより地方レベルで決定されるアクセス ポリシーの内容を定義するものではありません。

その標準を補完するものとして、ISO 21298 は、ポリシー交渉およびポリシーブリッジング (たとえば、アクセス決定の交渉段階中) をサポートするために国際的に使用できる一連の構造的役割と機能的役割を定義しています。この文書もその標準の採用を前提としており、それに準拠しています。

この文書で定義されているポリシー モデルと HL7 ヘルスケア プライバシーおよびセキュリティ分類システムとの関係は、付録 B で説明されています。

ISO 27789 は、電子医療記録システム内で発生する可能性のあるすべてのイベントに関連する監査ログおよび監査証跡情報の包括的な表現を定義します。これには、リポジトリとシステム間の EHR データの通信が含まれます。この文書は、ISO 27789 監査ログ モデルのプロファイル (サブセット) を定義します。この文書は、ISO 27789 監査ログ モデルのプロファイル (サブセット) を定義します。これは、特定の患者の EHR に誰がアクセスしたかに関する情報を患者およびその他の権限のある関係者と通信することを目的としています。なぜ。

ISO 18308 には、多数の EHR 固有の医療法的および倫理的要件が規定されていますが、これらへの準拠は主に EHR 参照モデル (ISO 13606-1 で発行) の特定のクラスと属性を通じて満たされます。 ISO 13606 標準は全体として ISO 18308 への準拠を可能にし、この文書は特にその倫理的および法的要件と公平な情報原則への準拠を可能にします。

05 EHR アクセス ポリシー モデル

0.5.1 全体的なアプローチ

ISO 13606-1 参照モデルでは、EHR_EXTRACT 内のすべての COMPOSITION にオプションの access_policy_ids 属性が含まれており、EHR 包含階層内で任意の粒度レベルでそのようなポリシーへの参照を行うことができます。したがって、すべての COMPOSITION は、今後のアクセスに必要なプリンシパル (ユーザー、エージェント、ソフトウェア、デバイス、委任されたアクターなど) の意図された権限とプロファイルを定義する、任意の数のアクセス ポリシーまたは同意宣言を参照できます。アクセスポリシー情報を表現および伝達するための第 7 条の情報モデルは、さまざまな国や地域の医療ネットワークで規定されるポリシー基準の多様性を考慮して、意図的に非常に汎用的なものに保たれています。モデルの主要なプロパティのいくつかの標準化された語彙は、デフォルトの用語リストとして定義されます。適切な場合には常にこれらを採用することが推奨されますが、管轄区域には、これらの国際標準化された用語リストを採用できないことを意味する要件、法律、または既存の投資がある可能性があることが認識されています。したがって、この文書は、管轄区域が代替用語リストを使用して適合性を宣言することを許可します。

医療とケアの環境は、従来の医療現場、社会的ケア、非公式の介護者、ボランティア団体（福祉慈善団体など）、患者自身、家族、そして場合によってはそのソーシャルネットワークの機関や関係者の複雑なネットワークで構成されることが増えています。これらすべては、個人の健康データのデータ共有を許可する契約を確立する場合があります。この「仮想ケア チーム」の動的な性質を考慮すると、これらのデータ共有契約を従来の人間対人間の文書ベースの方法で交渉することは現実的ではない可能性があります。したがって、そのような機関は、それぞれが準拠する標準、それぞれの特権ドメイン間のマッピング、および各特権ドメイン内でのデータの処理方法を事前に指定する枠組み協定を確立する可能性があります。上で述べたように、この政策モデルでは、管轄区域が代わりに使用する代替用語リストを宣言することが許可されています。これにより、複雑なデータ共有環境では、その環境におけるより広範囲のアクターと役割を説明するために、潜在的により豊富な新しい語彙を確立する必要がある可能性があることを認識し、この文書の採用にある程度の柔軟性が与えられます。

多くの既存システムやレガシー システムには、詳細に定義されたポリシー仕様を組み込むことができない可能性があり、多くの医療地域では、数年間そのようなポリシーを定義できる状況にない可能性があります。したがって、第 7 項の全体的なポリシー モデルを補足するものとして、この文書は、アクセス ポリシーの決定を行うための最小限の基礎を提供し、粗粒レベルではあるものの、基本レベルのアクセス ポリシーの相互運用性を確保できる 2 つの語彙を定義します。

これら 2 つの語彙は次のとおりです。

  • a) EHR データの感度分類 (COMPOSITION レベル)
  • b)一連の機能的役割による、EHR 要求者と受信者の高レベルの分類。

0.5.2 EHR データを扱う際の「知っておくべきこと」の定義

多くの医療環境 (患者への直接ケアの提供に関与する連携する医療チーム内および医療チーム間) では、医療記録情報をオープンに共有することが一般的です。実際、チームがこれを行うことは大多数の患者の願いであり、多くの患者は、安全性と治療の良好な継続のために、本来共有されるべきなのに、自分の健康記録が今日ほとんど共有されていないことに実際に驚いている。

現代の医療システムでは、保持する医療記録に対して複雑な内部アクセス制御パーティションを (紙上または電子的に) 定義しているものはほとんどありません。多数のきめ細かいアクセス ポリシーを定義することが有益であると考えられたとしても、実際には、医療システム、国民医療サービス、および何百万もの患者が、すべての EHR データに対して適切なアクセス コントロール ポリシーを指定し、多くの複雑なポリシーブリッジ計算をリアルタイムで実行できるソフトウェアコンポーネントを実装します。各患者の臨床ケア要件が変化するにつれて、これらのポリシーを維持することも複雑なプロセスになります。

理論的には、特定の EHR 内でマルチレベルのアクセス レベルのフレームワークを提供するために、一連のアクセス ポリシーが (患者または他の人によって) 定義される可能性がありますが、実際には、ほとんどの臨床現場は、医療記録全体で付与されるデフォルトの権限に基づいて動作します。その患者に正当な利害関係を持つ医療または健康関連の専門家。 (そのような正当な利益を誰が持つかの定義は組織によって異なり、この文書の範囲ではありません。) ただし、患者や専門家がより個人的な機密性の高い EHR へのアクセスを制限する必要がある場合があることも十分に受け入れられています。データ。また、ほとんどの医療サービスでは、特定の臨床現場を EHR の独占的部分として囲むことも一般的です (性的健康クリニックなど)

この種の臨床現場のリングフェンスや EHR データを特に機密としてマークすることは、たとえばがんや糖尿病の部分を定義するなど、診療専門分野内のナビゲーションやワークフローを支援するために定義される EHR の下位区分とはまったく異なります。 EHR内で。図 4 は、EHR が知る必要があるという観点から論理的に細分化される方法を示しています。機密性の分類 (機密性) は、ユーザーのクラスおよび特定のケア設定を通じて表されます。

図 4 — EHR の例内のアクセス ドメインの図

Key

AGP と共有されるプライベート エントリ
Bエントリーは性的健康チームに限定されています
C管理スタッフがアクセスできるエントリ
D臨床サポートスタッフがアクセスできるエントリ
E直接のケアチームがアクセスできるエントリ
Fプライベートエントリは複数の指定当事者と共有されます
G入国は刑務所の保健サービスに限定される

この図では、患者が自分の EHR に完全にアクセスできると想定されています。この患者の EHR の大部分は、直接臨床ケアを提供する関係者であれば誰でもアクセスできます。ただし、EHR にはいくつかのプライベート エントリが含まれています。一部は患者のかかりつけ医に限定されており、一部は指定当事者の別のリストに限定されています。 EHR には、性的健康クリニックによって作成され、それに制限されているエントリと、刑務所の保健サービスに制限されているエントリも含まれています。どちらのエントリにも、そのサブドメインに対する関連する追加権限を持つ関係者のみがアクセスできます (ただし、患者が他の関係者を指名する場合もあります)希望に応じて EHR のこれらのサブセットにアクセスできます)特権の 1 つの側面は、組織による臨床医への役割の割り当てであり、緊急時に行使される可能性があり、通常の役割を超える特権が与えられます。このような緊急オーバーライドにより、たとえば、その臨床医が通常管理しているよりも広範な患者記録へのアクセスが可能になる可能性があります（緊急ステータスのそのような使用は、特別に記録され、定期的にレビューされる必要があります）。

EHR の一部の部分は、調査の計画や実行などのタスクを実行するために特定の臨床所見をレビューする必要がある場合がある臨床サポート スタッフも意図的にアクセスできるようになっています。このサンプル EHR のごく一部には、管理スタッフもアクセスできるようになっています。予約担当者、秘書、ポーターはすべて、効率的なケアの提供全体において役割を果たすために、患者に関する特定の重要な事実を知る必要があります。たとえば、患者に特別な健康擁護のニーズがあること、または 24% の健康擁護のニーズがあることを知る必要があります。放射線科への搬送には酸素と車椅子が必要です。

この例では、EHR の一部へのアクセスから患者をどのように除外できるかについては説明していませんが、データ保護法の下で許可されている場合には、そのような規定は第 7 条の一般的なポリシーの枠組みを使用して行うことができます。この例としては、EHR データが患者の親族によって内密に提供された場合などが挙げられます。

特定の種類の患者、特定の環境、または単にある患者が他の患者よりも EHR を懸念しているという理由だけで、一連の豊富なポリシーが定義される可能性がありますが、分散型 EHR ソリューションの導入は、機密性の高い情報に基づいて管理する必要があります。一連のデフォルトと単純なフレームワークによって、近い将来、ほとんどのケースが満たされるでしょう。これは、豊富なポリシーのセットは、たとえそれらのポリシー内の情報が標準化された方法で伝達できたとしても、直接解釈して EHR 受信者の EHR システム内に組み込むことができない可能性があるためです。

したがって、この文書は、EHR アクセス ポリシー情報の一般的な表現に加えて、6.1 で定義された分類に従って EHR_EXTRACT 内の COMPOSITION の機密性を指定することにより、EHR_EXTRACT 内の EHR データの機密性を伝達するための最小基準の仕様も定義します。 。この分類は、図 4 に示す EHR データのさまざまなサブドメインに対応します。

実際には、特定の EHR システムには、EHR データの機密性を示すための他のメカニズムや同等の概念が備わっている場合があります。この文書では、EHR システムが 6.1 で定義された機密レベルに従ってデータを保存することは要求されていませんが、EHR_EXTRACT の生成時にこの分類にマッピングできることは要求されません。

0.5.3 EHR データにアクセスするための機能的役割

アクセスを決定するには、提案された EHR 受信者のプロファイルと目的が、要求された特定の RECORD_COMPONENTS の機密性を含め、EHR プロバイダーが保持する EHR に適用されるポリシーと一致する必要があります。

したがって、要求者および/または受信者のプロファイルは相互運用可能な方法で指定する必要があります。前述したように、これに使用される要件、法律、属性、語彙は各国で異なり、まだ標準化できません。

ただし、基本レベルの相互運用性を提供するには、この文書に最低限準拠する必要があります。EHR_EXTRACT に対するリクエストには、リクエスト仕様の一部として、6.2 で定義され、以下に対応する対象となる EHR 受信者の機能的役割が含まれる必要があります。 ISO 21298 で定義されている用語、 or 管轄区域で指定された代替用語リストが使用されること。

アクセス要求の許可または拒否、または EHR_EXTRACT のフィルタリングを目的とした、機能的役割と EHR 感度の間の相関関係は、s 6.3 で定義されています。

このマッピングは、アクセス要求を行っている当事者の種類に応じて EHR アクセスの範囲を制限する基本的な (大まかな) 方法を提供します。リクエスタ プロファイルの相互運用可能な仕様が地方レベルまたは国家レベルで定義されている状況では、いつでも高度な機能を追加できます。この基本的なマッピングを少数の追加仕様と組み合わせて、比較的豊富なアクセス制約のセットを指定する方法の図は、付録 A に提供されています。

0.6 監査ログの相互運用性

EHR システムとのやり取りの詳細は監査可能にするために保持する必要があることは広く認識されています。ただし、この種の監査ログを実装する方法は各 EHR システムに非常に固有であり、部分的には採用される永続性 (データベース ストレージなど) アプローチによって決定され、部分的には地域または国の法律によって指示される場合もあります。

EHR 監査証跡の要件は、ISO 27789:2013 医療情報学 – 電子医療記録の監査証跡で指定されています。この標準は、情報システムおよびドメイン全体で個人の健康情報の完全なセットを監査可能に保つために、監査トリガー イベントと監査データの観点から、EHR の監査証跡の共通フレームワークを指定します。

しかし、患者が自分の EHR データへのアクセスに関する情報を確認できることは正当な権利であるだけでなく、実際に本当に見る必要のある記録のみにアクセスするという医療従事者の道徳的行動を奨励するのに役立つという証拠が増えています。個々の EHR システムは監査ログへのある程度のアクセスを提供できる場合がありますが、現時点ではこれは通常、患者が自分の EHR のアクセス履歴を閲覧することを許可するには不適切なツールやインターフェイスを使用してデータベース管理者に提供されています。分散 (共有) EHR シナリオでは、EHR とそのアクセスのログも必然的に分散されます。

したがって、EHR (EHR システム内に保持されている) へのアクセスのリストを提供するという (患者またはその代理人による) 要求に応じて提供できるデータの基本セットには、相互運用可能な仕様が必要です。したがって、これは、この文書では監査ログ レビュー情報モデルとして、また ISO 13606-5 では要求と応答のインターフェイス モデルとして定義されています。将来の EHR システムおよび監査ログ システムは ISO 27789 への準拠を強化し、その構造を反映する内部データ モデルやインターフェイスを持つ可能性があるため、この文書の第 8 項の監査ログ モデルには ISO 27789 へのマッピング情報が含まれています。すべてではありません。アクセスされる EHR データの種類を説明する詳細の一部は EHR システム自体から取得する必要があるため、この文書の監査ログ モデルのプロパティは ISO 27789 と一致しています。

この監査ログ ビューは、EHR システムへのアクセスの正式な調査の一部として監査ログを検査する手段として、または監査証跡システム間の相互運用可能な通信を目的としたものではありません。

Introduction

0.1 General

This document, is part of a five-part standard series, published jointly by CEN and ISO through the Vienna Agreement. In this document, dependency upon any of the other parts of this series is explicitly stated where it applies.

0.2 Challenge addressed by this document

The communication of electronic health records (EHRs) in whole or in part, within and across organisational boundaries, and sometimes across national borders, is challenging from a security perspective. Health records should be created, processed and managed in ways that assure the confidentiality of their contents and legitimate control by patients in how they are used. Around the globe, these principles are progressively becoming enshrined in national data protection legislation. These instruments declare that the subject of care has the right to play a pivotal role in decisions on the content and distribution of his or her electronic health record, as well as rights to be informed of its contents. The communication of health record information to third parties should take place only with patient consent (which can be any freely given specific and informed indication of his or her wishes by which the data subject signifies his or her agreement to personal data relating to him or her being processed). More details can be found in ISO 22600-3. For EHR communication across national borders, ISO 22857 provides guidance that can be used to define appropriate security policy specifications.

Ideally, each fine grained entry in a patient's record should only be accessed by those persons who have permissions to view that information, specified by or approved by the patient and reflecting the dynamic nature of the set of persons with legitimate duty of care towards the patient through his or her lifetime. The access control list will ideally also include those persons who have permissions to access the data for reasons other than a duty of care (such as health service management, epidemiology and public health, consented research) but exclude any information that they do not need to see or which the patient feels is too personal for them to access. On the opposite side, the labelling by patients or their representatives of information as personal or private should ideally not hamper those who legitimately need to see the information in an emergency, nor accidentally result in genuine health care providers having such a filtered perspective that they are misled into managing the patient inappropriately. Patients' views on the inherent sensitivity 1 of entries in their health record can evolve over time, as their personal health anxieties alter or as societal attitudes to health problems change. Patients might wish to offer some heterogeneous levels of access to family, friends, carers and members of their community. Families might wish to provide a means by which they are able to access parts of each other’s records (but not necessarily to equal extents) in order to monitor the progress of inherited conditions within a family tree.

Such a set of requirements is arguably more extensive than that required of the data controllers in most other industry sectors. It is in practice made extremely complex by:

  • the large number of health record entries made on a patient during the course of modern health care;
  • the large number of health care personnel, often rotating through posts, who might potentially come into contact with a patient at any one time;
  • the large number of organisations with which a patient might come into contact during his or her lifetime;
  • the difficulty (for a patient or for anyone else) of classifying in a standardized way how sensitive a record entry might be;
  • the difficulty of determining how important a single health record entry might be to the future care of a patient, and to which classes of user;
  • the logically indelible nature of the EHR and the need for revisions to access permissions to be rigorously managed in the same way as revisions to the EHR entries themselves;
  • the need to determine appropriate access very rapidly, in real time, and potentially in a distributed computing environment;
  • the high level of concern expressed by a growing minority of patients to have their consent for disclosure recorded and respected;
  • the low level of concern the majority of patients have about these requirements, which has historically limited the priority and investment committed to tackling this aspect of EHR communications.

To support interoperable EHRs, and seamless communication of EHR data between health care providers, the negotiation required to determine if a given requester for EHR data should be permitted to receive the data should be capable of automation. If this were not possible, the delays and workload of managing human decisions for all or most record communications would obviate any value in striving for data interoperability.

The main principles of the approach to standards development in the area of EHR communications access control are to match the characteristics and parameters of a request to the EHR provider’s policies, and to any access control or consent declarations within the specified EHR, to maintain appropriate evidence of the disclosure, and to make this capable of automated processing. In practice, efforts are in progress to develop international standards for defining access control and privilege management systems that would be capable of computer-to-computer negotiation. However, this kind of work is predicated upon health services agreeing a mutually consistent framework for defining the privileges they wish to assign to staff, and the spectrum of sensitivity they offer for patients to define within their EHRs. This requires consistency in the way the relevant information is expressed, to make this sensibly scalable at definition-time (when new EHR entries are being added), at run-time (when a whole EHR is being retrieved or queried), and durable over a patient’s lifetime. It is also important to recognize that, for the foreseeable future, diversity will continue to exist between countries on the specific approaches to securing EHR communications, including differing legislation, and that a highly prescriptive approach to standardization is not presently possible.

This document therefore does not prescribe the access rules themselves. It does not specify who should have access to what and by means of which security mechanisms; these need to be determined by user communities, national guidelines and legislation. However, it does define a basic framework that can be used as a minimum specification of EHR access policy, and a richer generic representation for the communication of more fine-grained detailed policy information. This framework complements the overall architecture defined in ISO 13606-1, and defines specific information structures that are to be communicated as part of an EHR_EXTRACT defined in ISO 13606-1. Some of the kinds of agreement necessary for the security of EHR communication are inevitably outside the scope of this document, and are covered more extensively in ISO 22600 (Privilege Management and Access Control).

It should be noted that there are a number of explicit and implicit dependencies on use of other standards alongside this document, for overall cohesion of an interoperable information security deployment. In addition to agreement about the complete range of appropriate standards, a relevant assurance regime would be required (which is beyond the scope of this document).

0.3 Communication scenarios

0.3.1 Data flows

The interfaces and message models required to support EHR communication are the subject of ISO 13606-5. The description here is an overview of the communications process in order to show the interactions for which security features are needed. Figure 1 illustrates the key data flows and scenarios that need to be considered by this document. For each key data flow there will be an acknowledgement response, and optionally a rejection may be returned instead of the requested data.

Figure 1 — Principal data flows and security-related business processes covered by this document

The EHR Requester, EHR Recipient and Audit Log Reviewer might be healthcare professionals, the patient, a legal representative or another party with sufficient authorization to access healthcare information. Both the EHR_EXTRACT and the audit log, if provided, might need to be filtered to limit the disclosure to match the privileges of the recipient. This aspect of access control is discussed later in this introduction (all parties shown here will need to maintain an audit log, not just the EHR Provider. However, for readability the other audit log processes are not shown or described here).

The following subclauses describe each data flow in Figure 1.

0.3.2 Request EHR data

This interaction is not always required (for example, EHR data might be pushed from Provider to Recipient as in the case of a discharge summary). The request interface needs to include a sufficient profile of the Requester to enable the EHR Provider to be in a position to make an access decision, to populate an audit log, and provide the appropriate data to the intended Recipient. In some cases the EHR Requester might not be the same party as the EHR Recipient – for example a software agent might trigger a notification containing EHR data to be sent to a healthcare professional. In such cases it is the EHR Recipient’s credentials that will principally determine the access decision to be made.

An EHR request might need to include or reference consents for access and mandates for care, for example by providing some form of explicit consent from the patient, or a care mandate.

The negotiation between Requester and Provider of EHR data will increasingly be automated, and the information included in this interaction should be sufficient to enable a fully computerised policy negotiation.

The requirements for this interaction will be reflected in the REQUEST_EHR_EXTRACT interface model defined in ISO 13606-5.

0.3.3 Generate EHR access log entry

This is assumed practice in any EHR system, but it is not specified as a normative interface because of the diverse approaches and capabilities in present-day systems. The internal audit systems within any EHR system are not required to be interoperable except in support of the model defined in Clause 8 of this document and the corresponding interface defined in ISO 13606-5.

0.3.4 Acknowledge receipt of the EHR request

No healthcare-specific security considerations.

0.3.5 Make access decision, filter EHR data

When processing the EHR request, policies pertaining to the EHR Provider and access policies in the EHR itself all need to be taken into account in determining what data are extracted from the target EHR. This document cannot dictate the overall set of policies that might influence the EHR Provider, potentially deriving from national, regional, organisation-specific, professional and other legislation.

A decision to filter the EHR data on the basis of its sensitivity and the privileges of the EHR Requester and Recipient will need to conform to relevant policies and might need to balance the clinical risks of denying access to information with the medico-legal risks of releasing information.

This document however does define an overall framework for representing in an interoperable way the access policies that might relate to any particular EHR, authored by the patient or representatives. These might not be stored in the physical EHR system in this way; they might instead, for example, be integrated within a policy server linked to the EHR server.

This access decision is discussed in more detail in Clause 7.

0.3.6 Deny provision of the EHR_EXTRACT

If the access decision is to decline, a coarse-grained set of reasons needs to be defined in order to frame a suitable set of responses from the EHR Provider. However, it is important that the denial and any reason given does not imply to the recipient that the requested EHR data does exist – even the disclosure of its existence could itself be damaging to a patient.

No healthcare-specific security considerations– the interface model is defined in ISO 13606-5.

0.3.7 Provide the EHR_EXTRACT

It should be noted that the EHR Recipient need not be the same as an EHR Requester, and indeed the provision of an EHR need not have been triggered by a request. It might instead have been initiated by the provider as part of shared care pathway or to add new data to an existing EHR.

The EHR_EXTRACT is required to conform to the Reference Model defined in ISO 13606-1, and to the interface model defined in ISO 13606-5.

The EHR_EXTRACT sh include or reference any relevant access policies, represented in conformance with this document, to govern any onward propagation of the EHR data being communicated. Policies may only be referenced if the EHR recipient is known to have direct access to the same information by another means.

0.3.8 Acknowledge receipt of EHR_EXTRACT

No healthcare-specific security considerations.

0.3.9 Generate EHR access log entry

As described in 0.3.3.

0.3.10 Request EHR access log view

This is now considered to be desirable practice, to enable a patient to discover who has accessed part or all of his/her EHR in an information-sharing environment. The scope of this interface, as defined in this document, is to request a view of the audit log that informs the recipient about who has accessed what parts of his or her EHR within a given EHR system, and when. This interface is not intended to support situations where a full inspection of an audit log is required for legal purposes or for other investigations. This interface is discussed in Clause 6.

The interface model is defined in ISO 13606-5.

0.3.11 Generate EHR access log entry

As described in 0.3.3.

0.3.12 Provide EHR access log view

This is desirable practice, and requires an interoperable representation of such an entry (or set of entries). This interface is discussed in Clause 6.

Although a legal investigation will require that an audit log is provided in a complete and unmodified form, the presentation of an audit log view to a patient or to a healthcare professional might require that some entries are filtered out (such as those referring to EHR data to which the patient does not have access).

The interface model is defined in ISO 13606-5.

0.3.13 Deny EHR access log view

If the request is not to be met, a coarse-grained set of reasons needs to be defined. However, it is important that the denial and any reason given does not imply to the recipient that the requested EHR data does exist – even the disclosure of its existence could itself be damaging to a patient.

No healthcare-specific security considerations– the interface model is defined in ISO 13606-5.

0.3.14 Acknowledge receipt of EHR access log view

No healthcare-specific security considerations.

0.3.15 Generate EHR access log entry

As described in 0.3.3.

0.4 Requirements and technical approach

0.4.1 Generic healthcare security requirements

The most widely accepted requirements for an overall security approach in domains handling sensitive and personal data are published in ISO/IEC 27002. This specifies the kinds of measures that should be taken to protect assets such as EHR data, and ways in which such data might safely be communicated as part of a distributed computing environment. A health specific guide to this general standard has been published in ISO 27799 (Health informatics – Security management in health using ISO/IEC 27002). This will facilitate the formulation of common security polices across healthcare, and should help promote the adoption of interoperable security components and services. ISO 22600 (Health informatics — Privilege management and access control) defines a comprehensive architectural approach to formally and consistently defining and managing such policies. For EHR communication across national borders ISO 22857 provides guidance that can be used to define appropriate security policy specifications.

The exact security requirements that need to be met to permit any particular EHR communication instance will be governed by a number of national and local policies at both the sending and receiving sites, and at any intermediate links in the communications chain. Many of these policies will apply to healthcare communications in general, and will vary between countries and clinical settings in ways that cannot and should not be directed by this document. The approach taken in drafting this document has therefore been to assume that generic security policies, components and services will contribute to a negotiation phase (the access decision) prior to sanctioning the communication of an EHR Extract, and will protect the actual EHR data flows.

This document therefore requires that an overall security policy or set of policies conforming to ISO 27799 is in place at all of the sites participating in an EHR communication, and also that these policies conform to national or trans-border data protection legislation. Additional polices might be required to conform to specific national, local, professional or organisation regulations applicable to the communication or use of EHR data. Defining such policies is beyond the scope of this document.

0.4.2 Relationship to other related security standards

Legitimate access to EHR data will be determined by a wide range of policies, some of which might exist as documents, some will be encoded within applications, and some within formal authorization system components. It is recognized that vendors and organisations differ in how they have implemented access control policies and services, and the extent to which these are presently computerized.

ISO 22600 (all parts) defines a generic logical model for the representation of the privileges of principals (entities), of access control policies that pertain to potential target objects, and of the negotiation process that is required to arrive at an access decision. Figure 2 depicts the concepts of Role Based Access Control defined in ISO 22600 (all parts).

Figure 2 — Main concepts and policy types defined in Role Based Access Control [ISO 22600 (all parts)]

Defining constraints on roles, processes, target objects and related privileges by policies, Figure 2 turns into Figure 3, according to ISO 22600 (all parts).

Figure 3 — Policy-driven RBAC Schema

As illustrated in Figure 3, principals (persons, agents etc.) are mapped to one or more Functional Roles, which will be influenced by the Structural Roles that they are permitted to hold. For example, a person who is medically qualified and a specialist in child health might hold one or more Structural Roles (such as Consultant Paediatrician at a hospital, Head of Child Screening for the region). Those Structural Roles might permit him or her at times to act with the Functional Role of Personal Clinician to a patient. The Functional Role might be persistent, or limited to a single user session. Functional Roles are mapped to permissions to perform particular operations (such as writing new entries in an EHR) and to particular objects (such as the EHR data which that role-holder is permitted to view).

For the purposes of this document, the Target_Component class shown in Figure 3 is the EHR data held by the EHR Provider. The Permission_Assignment association defines policies to permit or deny access to part or all of the EHR, which need also to be communicated to the EHR Recipient for onward adoption and propagation. Whilst this document assumes the adoption of that standard it is acknowledged that national operational structures and terminology will differ and that variances will be possible. However, this document only specifies the policy model as a framework to communicate actual access policies in an interoperable way. It does not itself define the content of the access policies that are to be determined at jurisdictional or more local levels.

As a complement to that standard, ISO 21298 define sets of Structural Roles and Functional Roles that can be used internationally to support policy negotiation and policy bridging (for example during the negotiation phase of an access decision). This document also assumes the adoption of that standard, and aligns with it.

The relationship of the policy model defined in this document to the HL7 Healthcare Privacy and Security Classification System is explained in Annex B.

ISO 27789 defines a comprehensive representation of audit log and audit trail information relating to all of the events that might occur within electronic health record systems. This includes the communication of EHR data between repositories and systems. This document assumes conformance to that standard, and defines a profile (sub-set) of the ISO 27789 audit log model specifically for the purpose of communicating with patients and other authorised parties’ information about who has accessed the EHR of a specified patient, when and why.

A large number of EHR-specific medico-legal and ethical requirements are expressed within ISO 18308, although compliance with these is primarily met through specific classes and attributes of the EHR Reference Model (published in ISO 13606-1). The ISO 13606 standard as a whole enables conformance to ISO 18308, and this document specifically enables conformance to its ethical and legal requirements and fair information principles.

05 EHR access policy model

0.5.1 Overall approach

In the ISO 13606-1 Reference Model every COMPOSITION within the EHR_EXTRACT includes an optional access_policy_ids attribute to permit references to such policies to be made at any level of granularity within the EHR containment hierarchy. Every COMPOSITION may therefore reference any number of access policies or consent declarations that define the intended necessary privileges and profiles of principals (users, agents, software, devices, delegated actors etc.) for future access to it. The information model in Clause 7 for representing and communicating access policy information has been deliberately kept very generic, to allow for the diversity of policy criteria that will be stipulated in different countries and regional healthcare networks. Standardized vocabularies for some of the main properties of the model are defined as default term lists. Although it is recommended that these be adopted whenever they are suitable, it is recognised that jurisdictions might have requirements or legislation or existing investments that mean that they cannot adopt these internationally-standardised term lists. This document therefore permits jurisdictions to declare conformance using alternative term lists.

Health and care environments increasingly comprise complex networks of agencies and actors from traditional healthcare settings, social care, informal carers and voluntary agencies (such as welfare charities) patients themselves, families and sometimes their social networks. All of these might at times establish agreements to permit data sharing of personal health data. Given the dynamic nature of this"virtual care team" it might not be practical for these data sharing agreements to be negotiated in traditional human to human document based ways. It is therefore likely that such agencies will establish framework agreements that specify in advance the standards they each comply with, any mappings between their respective domains of privilege and how data are to be handled within each such privilege domain. As stated above, this policy model permits jurisdictions to instead declare alternative term lists that they will use. This allows for some flexibility in adoption of this document, recognising that complex data sharing environments might need to establish new, potentially richer, vocabularies to describe the wider range of actors and roles in that environment.

A number of existing and legacy systems might not be able to incorporate richly-defined policy specifications, and many healthcare regions might not be in a position to define such policies for some years. Therefore, as a complement to the overall policy model in Clause 7, this document defines two vocabularies that can provide a minimum basis for making an access policy decision, and ensure a basic level access policy interoperability, albeit at a coarse-grained level.

These two vocabularies are:

  • a) a sensitivity classification of EHR data (at the level of COMPOSITION);
  • b) a high-level classification of EHR Requesters and Recipients, through a set of Functional Roles.

0.5.2 Defining 'Need to Know' when handling EHR data

Within many healthcare environments (within and between collaborating healthcare teams involved in the direct provision of care to patients) the norm is to share health record information openly. It is indeed the wish of the vast majority of patients that teams do this, and many patients are actually surprised at how little of their health record is shared today when it should be, for safety and for good continuity of care.

Few contemporary healthcare systems (on paper or electronically) define complex internal access control partitions to the health records that they hold. Even if it were considered useful to define numerous fine-grained access policies, in practice it might take health care systems, national health services and millions of patients quite a long time to specify suitable access control policies for all of their EHR data, and to implement software components that can perform many complex policy-bridging computations in real time. Maintenance of these policies as the clinical care requirements of each patient evolve would also be a complex process.

Whilst a suite of access policies might in theory be defined (by patients or by others) to provide a multi-level access level framework within any given EHR, in practice most clinical settings operate on the basis of default privileges granted throughout the health record to any healthcare or health-related professional who has a legitimate interest in that patient. (The definition of who has such a legitimate interest will vary between organisations, and is not the scope of this document.) However, it is also well accepted that patients and professionals might at times need to restrict access to some more personally-sensitive EHR data. It is also common in most health services to ring-fence certain clinical settings as having exclusive portions of an EHR (for example, sexual health clinics).

This kind of ring-fencing of clinical settings or the marking of EHR data as particularly sensitive is quite distinct from any sub-divisions of the EHR that might be defined to assist navigation and workflow within clinical specialties, for example by defining cancer or diabetes portions within the EHR. Figure 4 provides an illustration of the way in which an EHR might logically be subdivided from a need-to-know point of view, in which the confidentiality classification (sensitivity) is represented through classes of user, and for particular care settings.

Figure 4 — Illustration of access domains within an example EHR

Key

Aprivate entries shared with GP
Bentries restricted to sexual health team
Centries accessible to administrative staff
Dentries accessible to clinical support staff
Eentries accessible to direct care teams
Fprivate entries shared with several named parties
Gentries restricted to prison health services

In this illustration, it is assumed that the patient has complete access to his or her EHR. The majority of this patient’s EHR is accessible to any party providing direct clinical care. However, the EHR does contain several private entries; some are restricted to the patient’s general (family) practitioner and some to a separate list of named parties. The EHR also contains some entries created by and restricted to a sexual health clinic, and others restricted to the prison health service – both can only be accessed by parties with relevant additional privilege to that sub-domain (however, the patient might nominate other parties to access these subsets of the EHR if he or she wishes). One aspect of privilege is the assignment by an organisation of roles to a clinician that might be exercised in an emergency that confer privileges that exceed those of his or her normal role. Such an emergency override might, for example, confer access to a wider set of patient records than is normally under the care of that clinician (such use of an emergency status would need to be specifically logged and regularly reviewed).

Some parts of the EHR are deliberately also accessible to clinical support staff, who might need to review certain clinical findings in order to perform tasks such as planning or performing investigations. A very small part of this example EHR has also been made accessible to administrative staff. Appointments clerks, secretaries and porters all have need to know certain key facts about a patient in order to play their role in the overall delivery of efficient care, such as knowing that a patient has special health advocacy needs or that he will need to have 24 % oxygen and a wheelchair in order to be transported to the radiology department.

This example does not illustrate how patients can be excluded from access to portions of the EHR, but such stipulations can be made using the generic policy framework of Clause 7, if permitted under data protection legislation. An example of this will be if the EHR data was provided in confidence by a relative of the patient.

Whilst a set of rich policies might be defined for specific kinds of patients, specific settings, or just because one patient is more concerned about his or her EHR than another, the adoption of distributed EHR solutions needs to be managed on the basis that a sensible set of defaults and a simple framework will satisfy the majority of cases in the near future. This is because a rich set of policies might not be capable of direct interpretation and incorporation within the EHR system of an EHR Recipient, even if the information in those policies can be communicated in a standardized way.

In addition to the generic representation of EHR access policy information, this document therefore also defines a specification for a minimum basis for communicating the sensitivity of EHR data within an EHR_EXTRACT, by specifying the sensitivity of the COMPOSITIONs within it according to the classification defined in 6.1. This classification corresponds to the various sub-domains of EHR data illustrated in Figure 4.

In practice any given EHR system might have other mechanisms for indicating the sensitivity of EHR data or some equivalent concept. This document does not require EHR systems to store data according to the sensitivity levels defined in 6.1, but to be able to map to this classification on generating an EHR_EXTRACT.

0.5.3 Functional Roles for accessing EHR data

In order to make an access decision, the profile and purpose of a proposed EHR Recipient need to be matched to the policies applying to the EHR held by the EHR provider, including the sensitivity of the specific RECORD_COMPONENTS that have been requested.

The profile of the requester and/or recipient therefore needs to be specified in an interoperable way. As discussed earlier, the requirements, legislation, attributes and vocabularies used for this in each country vary, and cannot yet be standardized.

However, in order to provide a basic level of interoperability minimum conformance to this document does require either that any request for an EHR_EXTRACT include, as part of the request specification, the Functional Role of the intended EHR Recipient, as defined in 6.2 and corresponding to those defined in ISO 21298, or that an alternative jurisdictionally-specified term list be used.

The correlation between Functional Role and EHR sensitivity, for the purpose of granting or denying an access request, or for filtering the EHR_EXTRACT, is defined in s 6.3.

This mapping provides a basic (coarse-grained) way of limiting the scope of EHR access according to the kind of party who is making the access request. Additional sophistication can always be added in situations for which an interoperable specification of the requester profile has been defined at a local or national level. An illustration of the way in which this basic mapping might be combined with a small number of additional specifications to specify a relatively rich set of access constraints is provided in Annex A.

0.6 Audit log interoperability

It is widely recognized that the details of interactions with an EHR system need to be retained for auditability purposes. However, the way in which these kinds of audit logs are implemented is quite specific for each EHR system, partly determined by the persistence (such as database storage) approach adopted, and might also partly be directed by local or national legislation.

Requirements for EHR audit trails are specified in ISO 27789:2013 Health informatics – Audit trails for electronic health records. That standard specifies a common framework for audit trails for EHRs, in terms of audit trigger events and audit data, to keep the complete set of personal health information auditable across information systems and domains.

However, there is increasing evidence that the ability for patients to be able to review information about access to their EHR data is not only a legitimate right but actually helps encourage moral behaviour amongst healthcare professionals in accessing only the records they genuinely need to see. Whilst individual EHR systems might be able to provide some degree of access to the audit log, this is at present usually provided to database administrators using tools and interfaces that are unsuitable for permitting patients to browse their own EHR’s access history. In a distributed (shared) EHR scenario the EHR, and logs of accesses to it, are inevitably distributed too.

An interoperable specification is therefore required for a basic set of data that can be provided in response to a request (by a patient or his/her representative) to provide a list of accesses to the EHR (held within an EHR system). This is therefore defined both as an audit log review information model in this document and as a request and response interface model in ISO 13606-5. Since future EHR systems and audit logging systems will increasingly conform to ISO 27789, and might therefore have internal data models and/or interfaces that reflect its structure, the audit log model in Clause 8 of this document includes mapping information to ISO 27789. Not all properties of the audit log model in this document have correspondence with ISO 27789, as some details describing the kind of EHR data accessed will need to be taken from the EHR system itself.

This audit log view is not intended as the means by which an audit log is examined as part of a formal investigation of accesses to an EHR system, nor for interoperable communications between audit trail systems.

ISO PDF プレビュー