[wiki:"Archtectural Overview index" TOC] [wiki:"Archtectural Overview Design of the openEHR EHR" PREV] [wiki:"Archtectural Overview Versioning" NEXT] [[TOC]] この文書は[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]の翻訳である。内容の正確性については保証しないので,適宜原文を参照してください。 = 7 セキュリティと機密保護 = 7 Security and Confidentiality == 7.1 要件 == #requirements 7.1 Requirements === プライバシー、機密保護、及び同意 === Privacy, Confidentiality and Consent プライバシー(個人データを閲覧できる人を限定する権利)および機密保護(開示されたデータのプライバシーの尊重についての閲覧者の責務)は、eHealthシステムに関する多くの利用者の主要な関心事である。広く受け容れられた原則は、ケアの過程において患者からの信頼に基づいて医療専門職に提供された情報(直接か、検体等の観察や検査によるものかを問わず)は、患者が承認した場合にのみ第三者に手渡され、またその利用に供せられるべきである、より簡潔には、「データ共有には患者の同意による統制が必須」ということである。患者によってはさらに複雑な追加要件があって、健康情報の部分毎に異なるアクセスを許す、たとえば、大部分の健康情報は比較的オープンにアクセスを許容するが、性または精神関連の健康項目についてはアクセスを制限するということがある。健康情報の内部関係性がこのことを難しくしている。たとえば、診断が秘匿されていても、投薬リストによってセンシティブな状態が明らかになってしまうことがよくある。にもかかわらず、すべからく安全な治療には投薬内容のリストが必要であり、多くの臨床専門職にとって現在の投薬内容(とアレルギー)情報が利用できなければごく基本的なケアを行うためにも大きな問題となろう。 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. === ヘルスケア提供者の要件 === Requirements of Healthcare Providers 一方、ケアを提供する医療専門職は、関連データへの迅速なアクセスや、スクリーン上に表示されるものが間違いなく患者について語られるべきことの信頼に足る表現であることを望んでいる。緊急時には、患者の普段のケアには関与していない医療者にも健康記録へのアクセスが必要となる場合がある。関与することになる特定の医療者が誰なのかは平常時には知ることができないので同意をとることはできないから、このような場合に限ってのアクセスは一般に同意されよう。 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. 一般的にヘルスケアの研究者は、現行のケアを評価し改善するため(医療知識発見)、及び教育的目的のために、大量の患者データへのアクセスを求める。後に挙げたこれらのニーズは、いずれも究極的には患者や社会の優先事項でもある。したがって、効果的なケアの提供と、進行中の医療研究への支援は、患者の同意コンセプトを実装したシステムによって機能させなければならない。 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. === アクセス制御の指定 === Specifying Access Control 理論的には、患者や一部の医療専門職にとって、誰が患者レコードを見ることができるかを特定することは容易なことであろう。場合によっては、直接識別による特定、たとえば患者が長期の主治医を提供者IDで指名するといったことが可能である。除外設定なども同じやり方でできるかもしれない。たとえば、以前の医師について患者との個人的な関係に問題が生じた場合である。 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. だが、提供者側を個別に特定することは、患者が多数のスタッフが関与する診療情報システムに組み込まれていったり、及び/または、あらかじめ構築された関係が全くないような場合には、直ちに困難になる。e-処方箋やe-調剤の出現は、eHealthのマトリックス上にさらに大量の医療及び医療周辺従事者をもたらし、誰が患者データを見るべきかの個別指定という課題を実行不可能なものにしている。さらに、「定住しない」人々(軍人、芸能人、NGO職員、国際ビジネスマン、旅行業者、スポーツ選手…)のカテゴリーが大量にいて、かつ増加しており、この人たちについてはどこの国でケアが必要になるかさえ予知できない。この結果、カデゴリーやロール・タイプによって指定されるべきある種のアクセス制御が、不可避的に必要なものとなる。 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. === ロールについての課題 === The Problem of Roles 健康情報へのアクセス制御を実装するための困難な課題のひとつは、「ロール」すなわち、アクセス権付与が決定される時点におけるレコード上のユーザのステータスの定義である。原則としては、ロールはあらかじめ判明していてしかるべきである。たとえば、「看護師」、「一般内科医(GP)」、「精神科医」といったラベルは、比較的容易に個人にアサイン可能である。だが、もっと重要な種類のラベルは、(たとえば)個人的ケア提供者(例:主治医)、他のケア提供スタッフ(例:看護師や老人介護士)、サポート・スタッフ(例:病理医、放射線技師)といった人たちを区別するためのものである。患者へのケア提供という観点からすると、ヘルスケア専門職の専門レベルよりも、彼または彼女のその患者への現時点でのケア・プロセスとの関係性の方がおそらく重要のはずだ。 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. どの個人がいつの時期にこれらのカテゴリーのどれに当てはまるのか、あるいはこのような用語は異なるサイトや所轄においてもいかように定義されるのか、といったことは常に明白というわけではない。現実的には、「ケア提供者」といったロール・カテゴリーを、特定日における病棟看護師のそれといった特定のアイデンティティとして評価することは、EHRの中ではなく個別のケア提供環境の中で行われなければならない。したがって、EHR内の情報へのアクセスを決定するために,ケアを受ける患者にどのスタッフが担当するのかというケアを提供する側の知識にある程度依存することになるだろう。 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. ロール・ベースのアクセス制御は、病気や休日による臨時の交替やスタッフの不足によるロールの変更といった日常的な事実によってさらに複雑化する。さらに、医療秘書を雇用する臨床家が、レコードのセンシティブな部分(患者に対する彼自身の治療に関連して)へのアクセスや更新を彼女に要求するならば、最高レベルのアクセスが、医療のトレーニングを受けておらず、患者のケアに直接関与もしない人間に、たとえ10分間だけであっても発効されることになる。従って、あらゆるロール・ベースのシステムは、単に理論的な原則に基づくのではなく、現実世界における医療ケアの雑多な現実を考慮したものでなければならない。 Role-based access control is further complicated by the common fact of temporary replacements due to illness or holiday and role changes due to staff shortages. Further, if a physician employing a medical secretary requires her to access and update sensitive parts (relating to his own treatment of the patient) of the record, access at the highest level is effectively given to someone not medically trained or related directly to the patient's care, even if only for 10 minutes. Any role-based system therefore has to take into account the messy reality of clinical care in the real world rather than being based solely on theoretical principles. === ユーザビリティ === Usability セキュリティ及びプライバシーに関するメカニズムのユーザビリティは、健康記録のアーキテクチャーの重要な要件である。セキュリティの専門家の設計による細粒度のアクセス制御のための非常にエレガントなソリューションが、単純に運用にも耐えないことがある。なぜならば、患者や医師にとってそれを習得するのに長期間を要したり、スクリーン上での実際の使用の際にあまりに時間を消費したり、ソフトウェアとして安全に実装することが複雑すぎることになりうるからである。 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. 以下のセクションでは、EHRのセキュリティとプライバシーの主な要件に対するopenEHRのサポートについて記述する。 The following sections describe support in openEHR for the main security and privacy requirements of EHRs. == 7.2 セキュリティとプライバシーへの脅威 == #threats 7.2 Threats to Security and Privacy ヘルス・レコードにおいてセキュリティとプライバシーをサポートするいかなるモデルも、仮定された脅威についてのなんらかの観念に基づく必要がある。あまり詳細にわたることは避けるが、openEHRで仮定しているセキュリティへの脅威には以下が含まれている。(ここで「不適切」とは、患者の同意を得ておらず、また得られないであろうすべてのことがらを意味するものとする) * 患者識別における人的誤りにより、ある患者のヘルス・データが他の患者に間違って関連付けられること。患者の識別ミスは、ある患者の個人データが他の患者のレコードに入り込む事態を招く(プライバシーの侵害と医療事故を招く惧れがある)。あるいは、同一患者に実在する記録以外の記録を生じさせる(2つ、またはそれ以上の医療的に不完全な記録となる)。 * その患者の現在のケアには関与していない医療専門職や身体ケア提供の場にいるその他の者(すなわち病院内の全従業者を含む)による不適切なアクセス。 * その患者が知っている他の者(たとえば家族)による不適切なアクセス。 * 企業や他の機関(たとえば保険審査目的)によるヘルス・データへの不適切なアクセス。 * 営利や他の個人的動機に基づく、(たとえば有名人や政治家の)ヘルス・データの悪意の盗み出しやアクセス。 * ウイルス、ワーム、DoS攻撃等による、データ整合性や可用性への一般的な脅威。 * ソフトウェアの誤り(バグ、構成ミス、インターオペラビリティ上の不具合等)が、データ汚染またはディスプレイ表示やコンピュータ処理の誤りを生じさせ、結果として医療事故をもたらすこと。 Any model of how security and privacy are supported in the health record must be based on some notion of assumed threats. Without going into great detail, security threats assumed by openEHR include the following (here "inappropriate" means anything that is not or would not be consented to by the patient): * human error in patient identification, leading to incorrect association of health data of one patient with another. Mis-identification of patients can cause personal data for one patient to go into the record of another patient (leading to privacy violations and possibly clinical errors), or into a new record rather than the existing one for the same patient (leading to two or more clinically incomplete records); * inappropriate access by health professionals or others in the physical care delivery environment (including e.g. any worker in a hospital) not involved in the current care of the patient; * inappropriate access by other persons known to the patient, e.g. a by family member; * inappropriate access of health data by corporate or other organisations e.g. for purposes of insurance discrimination; * malicious theft of or access to health data (e.g. of a celebrity or politician) for profit or other personal motives; * generic threats to data integrity and availability, such as viruses, worms, denial of service attacks etc.; * failures in software (due to bugs, incorrect configuration, interoperability failures etc.) causing corruption to data, or incorrect display or computation, resulting in clinical errors. セキュリティ、機密保護、及び整合性をサポートするメカニズムを設計することに関する主要原則は、方式の如何によらず標的とされた不適切アクセスの発生可能性は、情報の見積られた価値に比例し、アクセスのためのコストに反比例するということを忘れてはなならない。ヘルス・データ・セキュリティに関するRoss Andersonの英国医師協会誌[[FootNote(see e.g. Ross Anderson - "Security in Clinical Information Systems" available at http://www.cl.cam.ac.uk/users/rja14/policy11/policy11.html.)]] 記事に倣うならば、あるアクセスを想定した場合、犯人は最も単純で安上がりですばやい方法を見つけ出そうとするものである。それは、ジェームズ・ボンドに触発されたテクノロジーよりも、贈収賄や強盗の手口に近い。openEHRは、実装するのは安価であるが、悪用は極めて難しく、可用性について妥協のない、比較的単純なメカニズムを提供することによって、この原則を実用に供する。 A key principle with respect to the design of mechanisms supporting security, confidentiality and integrity has to be kept in mind: the likelihood of any given mode of targeted inappropriate access is proportional to the perceived value of the information and inversely proportional to the cost of access. To paraphrase Ross Anderson's BMA paper1 on health data security, for a given access, the perpretrator will try to find the simplest, cheapest and quickest method, which is more likely to be bribery or burglary than James Bond-inspired technology. openEHR makes use of this principle by providing some relatively simple mechanisms that are cheap to implement but can make misuse quite difficult, without compromising availability. == 7.3 openEHRが提供するソリューション == #solution 7.3 Solutions Provided by openEHR === 7.3.1 概要 === #sol_overview 7.3.1 Overview セキュリティとプライバシーに関する具体的なメカニズムの多くは、openEHRのようなモデルの中にではなく、システムのデプロイ、特に認証、アクセス制御、及び暗号化の実装に見出される。openEHRの仕様とコア・コンポーネントの実装は、異なるサイト毎に要件が極めて多様であるために、多種の具体的なメカニズムを明確に定義するものではない。セキュアなLANのデプロイの多くが、その内部では最低限のセキュリティを要求するのに対し、webでアクセス可能なヘルス・レコード・サーバーはおそらく全く異なる要件をもっているだろう。openEHRが行っていることは、本質的に異なる要件と構成をもつデプロイが、それにもかかわらず標準的な手段で基本原則を実装できるだけの柔軟さをもった方法で、主要な要件のいくつかをサポートすることである。 Many of the concrete mechanisms relating to security and privacy are found in system deployments rather than in models such as openEHR, particularly the implementation of authentication, access control, and encryption. The openEHR specifications and core component implementations do not explicitly define many concrete mechanisms since there is great variability in the requirements of different sites - secure LAN deployments many require minimal security inside, whereas web-accessible health record servers are likely to have quite different requirements. What openEHR does is to support some of the key requirements in a flexible enough way that deployments with substantially different requirements and configurations can nevertheless implement the basic principles in a standard way. 図21は、openEHRのアーキテクチャーによって直接仕様化された主要なセキュリティ手段を示している。ここには、EHRとデモグラフィックの分離、およびEHR全体に対するアクセス制御オブジェクトが含まれる。バージョン付きオブジェクトのレベルでは、コミット・オーディット(必須)、電子署名及びハッシュが利用可能である。以下のセクションで、これらの機構についてより詳細に記述する。 FIGURE 21 illustrates the main security measures directly specified by the openEHR architecture. These include EHR/demographic separation and an EHR-wide access control object. At the level of versioned objects, commit audits (mandatory), digital signatures and hashes are available. The following subsections describe these features in more detail. [[Image(security2.gif)]] === 7.3.2 セキュリティ・ポリシー === #policy 7.3.2 Security Policy openEHR EHR内部及びそれ自身では、必要と考えられる最低限のセキュリティ・ポリシー・プロファイルだけが設定されており、一般的にはシステムのデプロイには十分ではない(すなわち、openEHRで定義されていないセマンティクスのレイヤーでは実装されるべき他の側面が残っている)。以下のポリシー原則は、openEHRに組み込まれている。 In and of itself, the openEHR EHR imposes only a minimal security policy profile which could be regarded as necessary, but generally not sufficient for a deployed system (i.e. other aspects would still need to be implemented in layers whose semantics are not defined in openEHR). The following policy principles are embodied in openEHR. ==== 一般 ==== * 整合性: ヘルス・レコード情報は削除できない。論理的な削除は、データがあたかも削除されたかのように見せる方法で実現される(バージョン制御で実装されている)。 * 監査証跡: コンテント・オブジェクト、及びEHRステータスやアクセス制御オブジェクトを含めEHRに対して行われたすべての変更について、ユーザー識別、タイム・スタンプ、理由、オプションとしての電子署名、及び該当バージョン情報による監査証跡が取られる。例外が一つあり、変更者が患者である場合には、シンボリックな識別子を用いることができる(openEHRでPARTY_SELF と呼ぶもの。次の点を参照のこと)。 * 匿名性: ヘルス・レコードの内容は、個人識別可能なデモグラフィック情報から分離されている。このことにより、EHRを盗んでも、所有者である患者を識別するための直接の手がかりが得られないといった構成が可能となる (もちろん間接的な手がかりを制御することはもっと難しい)。 識別できるEHRを盗むためには、2つのサーバーからのデータの窃盗、もしくは2台の物理的なコンピュータの窃盗さえもが必要であるが、これはデプロイの構成に依存する。 General * Indelibility: health record information cannot be deleted; logical deletion is achieved by marking the data in such a way as to make it appear deleted (implemented in version control). * Audit trailing: All changes made to the EHR including content objects as well as the EHR status and access control objects are audit-trailed with user identity, time-stamp, reason, optionally digital signature and relevant version information; one exception is where the modifier is the patient, in which case, a symbolic identifier can be used (known as PARTY_SELF in openEHR; see next point). * Anonymity: the content of the health record is separate from identifying demographic information. This can be configured such that theft of the EHR provides no direct clue to the identity of the owning patient (indirect clues are of course harder to control). Stealing an identified EHR involves theft of data from two servers, or even theft of two physical computers, depending on deployment configuration. ==== アクセス制御 ==== Access Control * アクセスリスト:アクセス制御のもっとも重要な原則は,ユーザーのアイデンティティ(誰が患者をケアしているのか)と時間(現在のケアのエピソードが継続され,どのくらい持続するのが妥当か,あとどのくらい続けられるのか)の双方について「関連性」を持つことである。EHRで定義することができるアクセス制御リストは,識別された個人やカテゴリーを示すものであり,カテゴリーにはロールタイプや特定のスタッフグループが示されるものである。 * アクセス設定に基づいたアクセス制御:ゲートキーパーはEHRのアクセスコントロール設定にアクセスしてアクセスを制御する。ゲートキーパーはEHR内部で知られるアイデンティティの一つとしてEHRが作り出されたときに確立され、通常は精神的に成人としての能力のある患者本人あるいは、親や法的保護者、支持者といった責任のある人によって務められる。ゲートキーパーはアクセス制御リストを誰が変更できるのか決定することができる。リストに対するすべての変更は、通常のデータ(通常のバージョニングのために得られた)に関して監査証跡される。 * プライバシー:患者は多くのレベルのプライバシーの一つをもつようにEHR内のCOMPOSITIONに記録することができる。プライバシーレベルの定義はopenEHRのモデルに固有の設定があるのではなく、使用についての法的権限内での同意あるいは標準により定義されるものである。 * ユーザビリティ:アクセス制御設定の一般的な考え方は、EHRでの情報の大部分と時間のほとんどについて影響する「思慮深い初期値」の一つである。EHRへの初期値は患者により設定できるものであり、アクセス決定の大部分を閉めるアクセス制御の振る舞いについて定義するものである。初期値としてのポリシーの例外はその後に加えられる。この方法により、EHRそれぞれにあるすべてのアイテムについてのセキュリティについて考える必要性を最小限に止めている。 * Access list: the overriding principle of access control must be "relevance" both in terms of user identity (who is delivering care to the patient) and time (during the current episode of care, and for some reasonable, limited time afterward). An access control list can be defined for the EHR, indicating both identified individuals and categories, the latter of which might be role types, or particular staff groups. * Access control of access settings: a gate-keeper controls access to the EHR access control settings. The gate-keeper is established at the time of EHR creation as being one of the identities known in the EHR, usually the patient for mentally competent adults, otherwise a parent, legal guardian, advocate or other responsible person. The gate-keeper determines who can make changes to the access control list. All changes to the list are audit-trailed as for normal data (achieved due to normal versioning). * Privacy: patients can mark Compositions in the EHR as having one of a number of levels of privacy. The definition of the privacy levels is not hard-wired in the openEHR models but rather is defined by standards or agreements within jurisdictions of use. * Usability: The general mentality of access control setting is one of "sensible defaults" that work for most of the information in the EHR, most of the time. The defaults for the EHR can be set by the patient, defining access control behaviour for the majority of access decisions. Exceptions to the default policy are then added. This approach minimises the need to think about the security of every item in the EHR individually. その他の最小限のEHRデプロイでも実装されるべきであり,openEHRのみの特色ではないセキュリティーポリシー原則について以下に示す。 Other security policy principles that should be implemented in even a minimal EHR deployment but are not directly specified by openEHR include the following. * アクセスログ: アプリケーションユーザーがEHRのデータを読み出したという記録はEHRシステムにログとして残されるべきである。現在のopenEHRではそのようなログに関するモデルの仕様を定めてはいないが将来的には策定するであろう。ユーザーにアクセスログが記録亜sれテイルという事実を知らせることによって,(特に他のアクセス制御が実装されていなくても)不適切なアクセスを抑制する効果があるという研究がある。読み出すためにアクセスしたという記録をログとして残すことがEHRの適切な構成要素の一つであるとすることに山道するものもいる。現在のopenEHRはこのアプローチに対してサポートしていない。 * 記録の分割: 患者データが別の患者のEHRで見つかった場合に,EHRのアクセスログはそのデータに誰がアクセスしたことがあるのか,引き続いて素の間違った情報によりどのような臨床的考え(例えば診断や処方の決定など)が決定されたのかどうかについてまず示すことができるような記録を持つべきである。 * 記録の結合: 同じ患者で1つ以上のEHRが見つかってその記録を1つにまとめることが必用となった場合には、患者別や関連することになりうる医療従事者についてアクセス制御リストを再評価すべきである。 * アクセスの時間制限: 医療職が患者記録を閲覧できる期間について制限する機構は実装されるべきである。通常は、ある医療機関でのケアに関するエピソードに関連する期間に加えて、フォローアップする期間や外来に関連する期間というように、その限定すべき期間が定義されている。エピソードの開始と終了は、openEHRではADMIN_ENTRYクラスのインスタンスとして記録されており、入院と退院についての詳細を含む情報である。 * 無拒否:記録の変更に対してデジタル署名をつけることが必須であれば、内容を拒否せず無条件で受け入れることができるようにopenEHRシステムでもサポートされている。デジタル署名(EHR EXTRACT)を伝達することは、EXTRACTを通信することをログに残すことと合わせてopenEHRでもサポートされている。こうすることで、システム間で情報が拒否されずに受け入れられることができる。(例えば、同じシステムのバックエンドからフロントエンドアプリケーションで伝えられるように) * 証明:ユーザーが以前に署名した鍵に応じて信用のレベルを許可するような機構が提供されているべきである。 * Access logging: read accesses by application users to EHR data should be logged in the EHR system. Currently openEHR does not specify models of such logs, but might do so in the future. Studies have shown that making users aware of the fact of access logging is an effective deterrent to inappropriate access (especially where other controls are not implemented). There are some proponents of the argument that even read-access logs should be made part of the content of the EHR proper; currently openEHR does not support this approach. * Record demerging: when data for a patient is found to be in another patient's EHR, the access logs for that EHR should be used to determine who has accessed that data, primarily to determine if subsequent clinical thinking (e.g. diagnoses, medication decisions) have been made based on wrong information. * Record merging: when more than one EHR is discovered for the same patient, and have to be merged into a single record, the access control lists have to be re-evaluated and merged by the patient and potentially relevant carers. * Time-limitation of access: mechanisms should be implemented that limit the time during which given health professionals can see the patient record. Usually, the outer limits are defined by the interval of the episode of care in an institution plus some further time to cover follow-up or outpatient care. Episode start and end are recorded in openEHR as instances of the ADMIN_ENTRY class, containing admission and discharge details. * Non-repudiation: if digital signing of changes to the record is made mandatory, non-repudiation of content can be supported by an openEHR system. The digital signing of communications (EHR Extracts) is also supported in openEHR; coupled with logging of communication of Extracts, this can be used to guarantee non-repudiation of information passed between systems (cf. information passed between back-end and front-end applications of the same system). * Certification: a mechanism should be provided to allow a level of trust to be formally associated with user signing keys. ポリシーの主要な特徴は患者がかかっている複数の医療機関で維持されている健康記録情報のように分散環境においても対応できなければいけないことである。AndersonがBMA研究で指摘したように、ポリシー要件はまた、大量のEHRにアクセスを確保することや、予測される攻撃からユーザーを保護するために必要となるものでもある。現在、これらはopenEHRのスコープの範囲外であるが、現実問題としてほとんどのEHRはこのような実装を現在持っている。次のセクションでは、openEHRがどのようにポリシー対象の最初に一覧することについてサポートしているかについて記述する。 A key feature of the policy is that it must scale to distributed environments in which health record information is maintained at multiple provider sites visited by the patient. As Anderson points out in the BMA study, policy elements are also needed for guarding against users gaining access to massive numbers of EHRs, and inferencing attacks. Currently these are outside the scope of openEHR, and realistically, of most EHR implementations of any kind today. The following sections describe how openEHR supports the first list of policy objectives. === 7.3.3 一貫性 === #integrity 7.3.3 Integrity ==== バージョニング ==== Versioning openEHRでもっとも基本的なセキュリティに関する特徴はデータの一貫性についてサポートしていることである。これは主にバージョニングモデルで提供されており、共通情報モデル(Common Information Model)や抽出情報モデル(Extract Information Model)にあるchange_controlパッケージで特徴付られている。物理的に内容が変更されることなく,新しいバージョンだけが作成されることから,EHRのデモグラフィックサービスにおける全ての情報のバージョニングを基盤としたchange-setは情報の一貫性についての指標を構成している。したがって,全ての論理的変更や削除は追加と同様に,既存の情報アイテムに対する変更ではなく,物理的には新しいバージョンのものと扱うように実装されている。情報の一貫性は明らかに実装の質に依存しているが,一方でもっとも単純で現実的な実装(1Version = 1コピー)では,一度しか書き込めないシステムであるためにきわめて高い安全性を提供できる。openEHRではCONTRIBUTIONとして知られるchange-setsを使って,すべてのアイテムについてユーザーが修正や作成,削除を行うことに対応して一貫性を持たせるための他のユニットを提供することができる。openEHRのバージョニングモデルは,すべての変更されたアイテムに対しての監査記録と定義されており,基本的な監査かつ/またはいくつかのデジタル署名された認証(例えば,上級スタッフによるもの)を付加したものである。これはopenEHRのレコードのどの部分のどの種類であっても書き込み記録は全てユーザー識別子,時間,理由と他にとりうるメタデータをつけてログとして記録される。バージョニングは45ページの[wiki:"Archtectural Overview Versioning" セクション8]で詳細に記載されている。 The most basic security-related feature of openEHR is its support for data integrity. This is mainly provided by the versioning model, specified in the change_control package in the Common Information Model, and in the Extract Information Model. Change-set based versioning of all information in the EHR and demographic services constitutes a basic integrity measure for information, since no content is ever physically modified, only new versions are created. All logical changes and deletions as well as additions are therefore physically implemented as new Versions rather than changes to existing information items. Clearly the integrity of the information will depend on the quality of the implementation; however, the simplest possible implementations (1 Version = 1 copy) can provide very good safety due to being write-once systems. The use of change-sets, known as Contributions in openEHR, provides a further unit of integrity corresponding to all items modified, created or deleted in a single unit of work by a user. The openEHR versioning model defines audit records for all changed items, which can be basic audits and/or any number of additional digitally signed attestations (e.g. by senior staff). This means that every write access of any kind to any part of an openEHR record is logged with the user identification, time, reason, and potentially other meta-data. Versioning is described in detail in section 8 on page 45. ==== デジタル署名 ==== Digital Signature openEHRのEHRの内部ではバージョン管理されるオブジェクトの各バージョンにデジタル署名がつけられることがある(たとえば,処方薬リストや受付ノートなどの,全ての論理アイテムの各バージョン)。署名はコミットされたVERSIONを表すopenEHRの標準表現(スキーマに基づくXMLのような)のハッシュ(MD5など)を秘密鍵により暗号(RSA-1など)かして作成される。openEHRで署名や文字列のダイジェストを定義するための候補となりうるものは,仕様が公開されていることと事故時記述的であることからOpenPGPメッセージ形式(IETF RFC24402[[FootNote(IETF RFC 2440 - http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-18.txt http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-18.txt)]])である。RFC2440を形式として使用することはPGPの分散証明書基盤を使用するように実装するのではなく,実際には何らかの証明書基盤を実装することになる。openEHRはこの点ではとらわれていない.もし,公開鍵やそれに同等な基盤が利用できるのであれば,暗号は省いてもよく,素の際には内容に関するダイジェストだけがもたらされることになる。署名はVERSIONオブジェクトに登録され,EHR Extract内部で便利に利用することもできる。このプロセスは図22に示されている。 The possibility exists within an openEHR EHR to digitally sign each Version in a Versioned object (i.e. for each Version of any logical item, such as medications list, encounter note etc.). The signature is created as a private-key encryption (e.g. RSA-1) of a hash (e.g. MD5) of a canonical representation (such as in schema-based XML) of the Version being committed. A likely candidate for defining the signature and digest strings in openEHR is the openPGP message format (IETF RFC24402), due to being an open specification and self-describing. The use of RFC2440 for the format does not imply the use of the PGP distributed certificate infrastructure, or indeed any certification infrastructure; openEHR is agnostic on this point. If no public key or equivalent infrastructure is available, the encryption step might be omitted, resulting in a digest only of the content. The signature is stored within the Version object, allowing it to be conveniently carried within EHR Extracts. The process is shown in FIGURE 22. [[Image(securitya.gif)]] バージョン管理システムでのデータの署名は,一貫性の確認(ダイジェストがこの役割を持つ)や,認証基準(署名がこの役割を持つ)や,拒否しない基準としての役割を持っている。バージョン管理された永続層自体をハッキングから防衛するためには,署名は信頼できる公証サービスに転送することもできる。デジタル書名を基盤とした十分に安全なシステムは,証明された公開鍵を必要とし,どのような環境でも利用することができるものもあれば,利用することができないこともある。デジタル署名を行うことの利点の一つは,局所的なリポジトリが破綻することに対してより回避するような一貫性を持ったアイテムであるEHRの大部分や全体に比べ手,EHR(単一バージョン)の比較的小さな部分である。 The signing of data in a versioning system acts as an integrity check (the digest performs this function), an authentication measure (the signature performs this function), and also a non-repudiation measure. To guard against hacking of the versioned persistence layer itself, signatures can be forwarded to a trusted notarisation service. A fully secure system based on digital signing also requires certified public keys, which may or may not be available in any given environment. One of the benefits of digitally signing relatively small pieces of the EHR (single Versions) rather than the whole EHR or large sections of it is that the integrity of items is more immune to localised repository corruptions. === 7.3.4 匿名性 === #anonymity 7.3.4 Anonymity セクション6.1で示したように,openEHRにおけるEHRの特徴の一つは,EHR(臨床や管理)情報とデモグラフィック情報を分離していることである。医療提供者は一般的に公的に知られているため,これについての参照が関連しているのは,主に医療提供者側の存在よりもむしろ患者側である。openEHRのPARTY_SELFオブジェクトとして差いられる特殊クラスは,EHRで対象を参照するために用いられる。PARTY_SELFインスタンスが唯一持つ情報は,付加的な対外参照である。openEHRのEHRは以下のようにこの外部識別子がPARTY_SELFインスタンスの実際の集合として三層に分かれて制御されるように設定することができる。 As described above in section 6.1, one of the features of the openEHR EHR is a separation of EHR (clinical and administrative) information and demographic information. This mainly relates to references to the patient rather than to provider entities, since the latter are usually publicly known. A special kind of object known as PARTY_SELF in openEHR is used to refer to the subject in the EHR. The only information contained in a PARTY_SELF instance is an optional external reference. The openEHR EHR can be configured to provide 3 levels of separation by controlling whether and where this external identifier is actually set in PARTY_SELF instances, as follows: * EHRでの実在しない場所(たとえば,全てのPARTY_SELFインスタンスが空の代替物である場合)これは,もっとも安全なアプローチであり,EHRとEHR外部で行われるべき患者をEHR.ehr_IDと目的識別子で関連付けることによってつなげることを意味している。このアプローチはより公開された環境により適応したものである。 * EHR STATUSオブジェクト(目的属性)で一度示されたものは他のどこにも存在しない。これもまた,EHR STATUSオブジェクトが何らかの方法で防御されるのであれば比較的安全な方法である. * PARTY_SELFのインスタンス全てにおいて。これは,安全な環境では合理的な解決法であり,ローカルにあるレコードを部分的にコピーする際にも便利である. * Nowhere in the EHR (i.e. every PARTY_SELF instance is a blank placeholder). This is the most secure approach, and means that the link between the EHR and the patient has to be done outside the EHR, by associating EHR.ehr_id and the subject identifier. This approach is more likely for more open environments. * Once only in the EHR Status object (subject attribute), and nowhere else. This is also relatively secure, if the EHR Status object is protected in some way. * In every instance of PARTY_SELF; this solution is reasonable in a secure environment, and convenient for copying parts of the record around locally. この単純な機構は適切に使われれば情報が盗まれたりハッキングされたりするようなことに対抗して基本的に保護することができる。もっとも安全な状況では,ハッカーはEHRデータだけではなく分離されたデモグラフィックレコードやクロス参照されたデータベースにあるアイデンティティも含めて盗み出す必要がある。このデモグラフィックレコードやアイデンティティは異なる機械に置くことができる(これにより盗み出すことが難しくなる)。アイデンティティのクロス参照データベースは他のセキュリティ機構で容易に暗号化したり保護したりすることもできる。 This simple mechanism provides a basic protection against certain kinds of information theft or hacking if used properly. In the most secure situation, a hacker has to steal not just EHR data but also separate demographic records and an identity cross reference database, both of which can be located on different machines (making burglary harder). The identity cross-reference database would be easy to encrypt or protect by other security mechanisms. == 7.4 アクセスコントロール == #control 7.4 Access Control アクセスコントロールの概要はopenEHRでEHRのためのEHR_ACCESSオブジェクトで完全に特定される。このオブジェクトはすべての情報にアクセスするゲートウェイとして働き、すべてのアクセスはそれに登録されるポリシーやルールに従い決定される。EHR ACESSオブジェクトのセマンティクスを定義するうえでの問題の一つは,健康情報を共有するために確立された公式のモデルが現在公開されていないことである。CEN EN13606 Part4の実績や,汎用セキュリティ標準であるISO/IEC17799をもとにした TC/215で検討されたISO PMAC(Privilege Management and Access Control,特権管理とアクセス制御)に関連する実績などをふくめて,様々な効果があげられつつあるというのが現状である。確かに,実験的で限定的に作られた健康情報に関するセキュリティ実装は存在する。しかし現実には大規模にEHRを共有するための実装は存在せず,それを解決するためのソリューションは今日まで未だ開発中の段階である。openEHRアーキテクチャはしたがって,ACCESS_CONTROL_SETTINGクラス(Security IM)のサブタイプとしてそれぞれ定義されるアクセス制御モデルを代替として適用するように設計されている。このアプローチは単純なアクセス制御モデルとして定義することができ,初めに実装して後でよりいっそう洗練されたモデルを利用することもできる。どの時点で使われる「スキーム」であっても常にEHR_ACCESSオブジェクトであることを示している。 Overview Access control is completely specified in an openEHR EHR in the EHR_ACCESS object for the EHR. This object acts as a gateway for all information access, and any access decision must be made based on the policies and rules it contains. One of the problems with defining the semantics of the EHR Access object is that there is currently no published formal, proven model of access control for shared health information. Various efforts underway include the CEN EN13606 part 4 work, the ISO PMAC (Privilege Management and Access Control) work being done in TC/215 based on the generic security standard ISO/IEC 17799. Undoubtedly experimental and even some limited production health information security implementations exist. In reality however, no large-scale shared EHR deployments exist, and so security solutions to date are still developmental. The openEHR architecture is therefore designed to accommodate alternative models of access control, each defined by a subtype of the class ACCESS_CONTROL_SETTING (Security IM). This approach means that a simplistic access control model can be defined and implemented initially, with more sophisticated models being used later. The "scheme" in use at any given time is always indicated in the EHR Access object. 1see e.g. Ross Anderson - "Security in Clinical Information Systems" available at [http://www.cl.cam.ac.uk/users/rja14/policy11/policy11.html http://www.cl.cam.ac.uk/users/rja14/policy11/policy11.html]. 2IETF RFC 2440 - [http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-18.txt http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-18.txt] [[FootNote]] [wiki:"Archtectural Overview index" TOC] [wiki:"Archtectural Overview Design of the openEHR EHR" PREV] [wiki:"Archtectural Overview Versioning" NEXT]