Changes between Version 13 and Version 14 of Archtectural Overview Security
- Timestamp:
- Feb 10, 2008, 6:36:11 PM (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Archtectural Overview Security
v13 v14 1 1 [wiki:"Archtectural Overview index" TOC] [wiki:"Archtectural Overview Design of the openEHR EHR" PREV] [wiki:"Archtectural Overview Versioning" NEXT] [[TOC]] 2 2 3 この文書は[http://svn.openehr.org/specification/TAGS/Release-1.0.1/publishing/html/architecture/overview/Output/front.html Archtectural Overview]の[http://svn.openehr.org/specification/TAGS/Release-1.0.1/publishing/html/architecture/overview/Output/security.html 7 Security and Confidentiality]の翻訳である。内容の正確性については保証しないので， 正確な内容については原文を参照すること3 この文書は[http://svn.openehr.org/specification/TAGS/Release-1.0.1/publishing/html/architecture/overview/Output/front.html Archtectural Overview]の[http://svn.openehr.org/specification/TAGS/Release-1.0.1/publishing/html/architecture/overview/Output/security.html 7 Security and Confidentiality]の翻訳である。内容の正確性については保証しないので，適宜原文を参照してください。 4 4 5 5 = 7 セキュリティと機密保護 = … … 7 7 8 8 == 7.1 要件 == 9 10 9 11 10 7.1 Requirements … … 14 13 Privacy, Confidentiality and Consent 15 14 16 プライバシー（個人データを閲覧できる人を限定する権利） 及び機密保護（開示されたデータのプライバシーの尊重についての閲覧者の責務）は、eHealthシステムに関する多くの利用者の主要な関心事である。広く受け容れられた原則は、ケアの過程において患者からの信頼に基づいて医療専門職に提供された情報（直接か、検体等の観察や検査によるものかを問わず）は、患者が承認した場合にのみ第三者に手渡され、またその利用に供せられるべきである、より簡潔には、「データ共有には患者の同意による統制が必須」ということである。患者によってはさらに複雑な追加要件があって、健康情報の部分毎に異なるアクセスを許す、たとえば、大部分の健康情報は比較的オープンにアクセスを許容するが、性または精神関連の健康項目についてはアクセスを制限するということがある。健康情報の内部関係性がこのことを難しくしている。たとえば、診断が秘匿されていても、投薬リストによってセンシティブな状態が明らかになってしまうことがよくある。にもかかわらず、すべからく安全な治療には投薬内容のリストが必要であり、多くの臨床専門職にとって現在の投薬内容（及びアレルギー）情報が利用できなければごく基本的なケアを行うためにも大きな問題となろう。15 プライバシー（個人データを閲覧できる人を限定する権利）および機密保護（開示されたデータのプライバシーの尊重についての閲覧者の責務）は、eHealthシステムに関する多くの利用者の主要な関心事である。広く受け容れられた原則は、ケアの過程において患者からの信頼に基づいて医療専門職に提供された情報（直接か、検体等の観察や検査によるものかを問わず）は、患者が承認した場合にのみ第三者に手渡され、またその利用に供せられるべきである、より簡潔には、「データ共有には患者の同意による統制が必須」ということである。患者によってはさらに複雑な追加要件があって、健康情報の部分毎に異なるアクセスを許す、たとえば、大部分の健康情報は比較的オープンにアクセスを許容するが、性または精神関連の健康項目についてはアクセスを制限するということがある。健康情報の内部関係性がこのことを難しくしている。たとえば、診断が秘匿されていても、投薬リストによってセンシティブな状態が明らかになってしまうことがよくある。にもかかわらず、すべからく安全な治療には投薬内容のリストが必要であり、多くの臨床専門職にとって現在の投薬内容（とアレルギー）情報が利用できなければごく基本的なケアを行うためにも大きな問題となろう。 17 16 18 17 Privacy (the right to limit who sees the personal data) and confidentiality (the obligation of others to respect the privacy of disclosed data) are primary concerns of many consumers with respect to e-Health systems. A widely accepted principle is that information provided (either directly or due to observation or testing of specimens etc.) in confidence by a patient to health professionals during an episode of care should only be passed on or otherwise become available to other parties if the patient agrees; put more simply: data sharing must be controlled by patient consent. A more complex sub-requirement for some patients is allowing differential access to parts of their health record, for example, relatively open access rights to most of the health record, but limited access to sexual or mental health items. The interrelatedness of health information can make this difficult. For example the medication list will often give away sensitive conditions even if the diagnosis is hidden, yet is needed for any safe treatment, and many health professionals would see the unavailability of current medications (and allergies) information as highly problematic for giving even basic care. … … 21 20 Requirements of Healthcare Providers 22 21 23 一方、ケアを提供する医療専門職は、関連データへの迅速なアクセスや、スクリーン上に表示されるものが間違いなく患者について語られるべきことの信頼に足る 代弁であることを望んでいる。健康情報への緊急のアクセスが、患者の普段のケアには関与していない医療者に必要となる場合があり、関与することになる特定の医療者が誰なのかは通常はわからないのであるから、このような場合に限ってのアクセスは一般に同意されよう。22 一方、ケアを提供する医療専門職は、関連データへの迅速なアクセスや、スクリーン上に表示されるものが間違いなく患者について語られるべきことの信頼に足る表現であることを望んでいる。緊急時には、患者の普段のケアには関与していない医療者にも健康記録へのアクセスが必要となる場合がある。関与することになる特定の医療者が誰なのかは平常時には知ることができないので同意をとることはできないから、このような場合に限ってのアクセスは一般に同意されよう。 24 23 25 24 On the other hand, clinical professionals delivering care want fast access to relevant data, and to be sure that what they see on the screen is a faithful representation of what has been said about the patient. Emergency access to health records is sometimes needed by carers otherwise unrelated to the normal care of a patient; such accesses can only be consented to in a general way, since the specific providers involved will not usually be known. 26 25 27 一般的にヘルスケアの研究者は、現行のケアを評価し改善するため（医療知識発見）、及び教育的目的のために、大量の患者データへのアクセスを求める。後に挙げたこれらのニーズは、いずれも究極的には患者や社会の優先事項でもある。 従って、効果的なケアの提供と、進行中の医療研究への支援は、患者の同意コンセプトを実装したシステムによって機能させなければならない。26 一般的にヘルスケアの研究者は、現行のケアを評価し改善するため（医療知識発見）、及び教育的目的のために、大量の患者データへのアクセスを求める。後に挙げたこれらのニーズは、いずれも究極的には患者や社会の優先事項でもある。したがって、効果的なケアの提供と、進行中の医療研究への支援は、患者の同意コンセプトを実装したシステムによって機能させなければならない。 28 27 29 28 Researchers in healthcare generally want access to the data of large numbers of patients in order to evaluate current care and improve it (clinical knowledge discovery), and for educational purposes. Both of these latter needs are also ultimately patient and societal priorities. Providing effective care and supporting ongoing medical research therefore have to function in a system that implements the concept of patient consent. 30 29 31 30 === アクセス制御の指定 === 32 Specifying Access Control 31 32 Specifying Access Control 33 33 34 34 理論的には、患者や一部の医療専門職にとって、誰が患者レコードを見ることができるかを特定することは容易なことであろう。場合によっては、直接識別による特定、たとえば患者が長期の主治医を提供者IDで指名するといったことが可能である。除外設定なども同じやり方でできるかもしれない。たとえば、以前の医師について患者との個人的な関係に問題が生じた場合である。 … … 36 36 In theory, it should be easy for the patient or some clinical professional to specify who can see the patient record. In some cases it is can be done by direct identification, e.g. the patient might nominate their long-term GP by provider id. Some exclusions could potentially be made this way as well, for example a previous doctor with whom the patient has a problematic personal relationship. 37 37 38 だが、提供者側を個別に特定することは、患者が多数のスタッフが 働くヘルスケアシステムに組み込まれていったり、及び／または、あらかじめ構築された関係が全くないような場合には、直ちに困難になる。e-処方箋やe-調剤の出現は、eHealthのマトリックス上にさらに大量の医療及び医療周辺従事者をもたらし、誰が患者データを見るべきかの個別指定という課題を実行不可能なものにしている。さらに、「定住しない」人々（軍人、芸能人、NGO職員、国際ビジネスマン、旅行業者、スポーツ選手…）のカテゴリーが大量にいて、かつ増加しており、この人たちについてはどこの国でケアが必要になるかさえ予知できない。この結果、カデゴリーやロール・タイプによって指定されるべきある種のアクセス制御が、不可避的に必要なものとなる。38 だが、提供者側を個別に特定することは、患者が多数のスタッフが関与する診療情報システムに組み込まれていったり、及び／または、あらかじめ構築された関係が全くないような場合には、直ちに困難になる。e-処方箋やe-調剤の出現は、eHealthのマトリックス上にさらに大量の医療及び医療周辺従事者をもたらし、誰が患者データを見るべきかの個別指定という課題を実行不可能なものにしている。さらに、「定住しない」人々（軍人、芸能人、NGO職員、国際ビジネスマン、旅行業者、スポーツ選手…）のカテゴリーが大量にいて、かつ増加しており、この人たちについてはどこの国でケアが必要になるかさえ予知できない。この結果、カデゴリーやロール・タイプによって指定されるべきある種のアクセス制御が、不可避的に必要なものとなる。 39 39 40 40 However it soon becomes difficult to identify provider parties individually when the patient moves into parts of the healthcare system where there are many staff, and/or where there is no previously established relationship. The advent of e-prescribing and e-pharmacy will bring even larger numbers of health and allied health workers into the e-Health matrix, making the problem of individual identification of who should see the patient's data infeasible. Further, there is a large and growing category of "very mobile" people (the military, entertainers, NGO workers, international business and tourism professionals, athletes....) who cannot predict even in which country they may require care. As a consequence, the need for some access control to be specified in terms of categories or role types appears inescapable. … … 47 47 One of the difficult challenges to implementing access control to health information is that of defining "roles", i.e. the status of users of the record at the time when right of access is being determined. In principle, roles ought to be knowable in advance. For example, the labels "nurse", "GP" and "psychiatrist" can be relatively easily assigned to individuals. However, the kinds of labels that are of more importance are those that differentiate among (for example) personal carers (e.g. primary GP), other care delivery staff (e.g. nurses, aged carers) and support staff (e.g. pathologists, radiographers). In a patient care delivery-oriented view of the world, the professional level of a health care professional is probably less important than his or her relationship to the current care process for the patient. 48 48 49 どの個人がいつの時期にこれらのカテゴリーのどれに当てはまるのか、あるいはこのような用語は異なるサイトや所轄においてもいかように定義されるのか、といったことは常に明白というわけではない。現実的には、「ケア提供者」といったロール・カテゴリーを、特定日における病棟看護師のそれといった特定のアイデンティティとして評価することは、EHRの中ではなく個別のケア提供環境の中で行われなければならない。 従って、EHR内の情報へのアクセスの意志決定は、所与の患者のケア・プロセスにおいてスタッフが能動的に関与している提供サイトのナレッジにある程度依存することになろう。49 どの個人がいつの時期にこれらのカテゴリーのどれに当てはまるのか、あるいはこのような用語は異なるサイトや所轄においてもいかように定義されるのか、といったことは常に明白というわけではない。現実的には、「ケア提供者」といったロール・カテゴリーを、特定日における病棟看護師のそれといった特定のアイデンティティとして評価することは、EHRの中ではなく個別のケア提供環境の中で行われなければならない。したがって、EHR内の情報へのアクセスを決定するために，ケアを受ける患者にどのスタッフが担当するのかというケアを提供する側の知識にある程度依存することになるだろう。 50 50 51 51 It will not always be clear which individuals fall into any of these categories at any time, or how such terms are even defined in different sites and jurisdictions. Realistically, the evaluation of a role category such as "care deliverer" into particular identities such as those of nurses on the ward on a particular day must be done in each care delivery environment, not in the EHR. Access decisions for information in the EHR therefore will have some dependence on provider site knowledge of which staff are actively involved in the care process of a given patient. … … 58 58 Usability 59 59 60 セキュリティ及びプライバシーに関するメカニズムのユーザビリティは、 ヘルス・レコードのアーキテクチャーの重要な要件である。セキュリティの専門家の設計による細粒度のアクセス制御のための非常にエレガントなソリューションが、単純に運用に耐えないことがある。なぜならば、患者や医師にとって学ぶのに長期間を要したり、スクリーン上での実際の使用の際にあまりに時間を消費したり、ソフトウェアとして安全に実装することが複雑すぎたりするからである。60 セキュリティ及びプライバシーに関するメカニズムのユーザビリティは、健康記録のアーキテクチャーの重要な要件である。セキュリティの専門家の設計による細粒度のアクセス制御のための非常にエレガントなソリューションが、単純に運用にも耐えないことがある。なぜならば、患者や医師にとってそれを習得するのに長期間を要したり、スクリーン上での実際の使用の際にあまりに時間を消費したり、ソフトウェアとして安全に実装することが複雑すぎることになりうるからである。 61 61 62 62 Usability of security and privacy mechanisms is a key requirement of a health record architecture. Some very elegant solutions to fine-grained access control designed by security experts would be simply unusable in practice because they would take too long for patients and doctors to learn, or are too time-consuming to actually use on the screen; they could also be too complex to safely implement in software.
