| 79 | | * 患者識別における人的誤りにより、ある患者のヘルス・データが他の患者に間違って関連付けられること。患者の識別ミスは、ある患者の個人データが他の患者のレコードに入り込む事態を招く(プライバシーの侵害と医療事故を招く惧れがある）。あるいは、同一患者に実在する記録以外の記録を生じさせる（2つ、またはそれ以上の医療的に不完全な記録となる）。 |
| 80 | | * その患者の現在のケアには関与していない医療専門職や身体ケア提供の場にいるその他の者（すなわち病院内の全従業者を含む）による不適切なアクセス。 |
| 81 | | * その患者が知っている他の者（たとえば家族）による不適切なアクセス。 |
| 82 | | * 企業や他の機関（たとえば保険審査目的）によるヘルス・データへの不適切なアクセス。 |
| 83 | | * 営利や他の個人的動機に基づく、（たとえば有名人や政治家の）ヘルス・データの悪意の盗み出しやアクセス。 |
| 84 | | * ウイルス、ワーム、DoS攻撃等による、データ整合性や可用性への一般的な脅威。 |
| 85 | | * ソフトウェアの誤り（バグ、構成ミス、インターオペラビリティ上の不具合等）が、データ汚染またはディスプレイ表示やコンピュータ処理の誤りを生じさせ、結果として医療事故をもたらすこと。 |
| | 72 | |
| | 73 | * 患者識別における人的誤りにより、ある患者のヘルス・データが他の患者に間違って関連付けられること。患者の識別ミスは、ある患者の個人データが他の患者のレコードに入り込む事態を招く(プライバシーの侵害と医療事故を招く惧れがある）。あるいは、同一患者に実在する記録以外の記録を生じさせる（2つ、またはそれ以上の医療的に不完全な記録となる）。 |
| | 74 | * その患者の現在のケアには関与していない医療専門職や身体ケア提供の場にいるその他の者（すなわち病院内の全従業者を含む）による不適切なアクセス。 |
| | 75 | * その患者が知っている他の者（たとえば家族）による不適切なアクセス。 |
| | 76 | * 企業や他の機関（たとえば保険審査目的）によるヘルス・データへの不適切なアクセス。 |
| | 77 | * 営利や他の個人的動機に基づく、（たとえば有名人や政治家の）ヘルス・データの悪意の盗み出しやアクセス。 |
| | 78 | * ウイルス、ワーム、DoS攻撃等による、データ整合性や可用性への一般的な脅威。 |
| | 79 | * ソフトウェアの誤り（バグ、構成ミス、インターオペラビリティ上の不具合等）が、データ汚染またはディスプレイ表示やコンピュータ処理の誤りを生じさせ、結果として医療事故をもたらすこと。 |
| 88 | | * 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); |
| 89 | | * 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; |
| 90 | | * inappropriate access by other persons known to the patient, e.g. a by family member; |
| 91 | | * inappropriate access of health data by corporate or other organisations e.g. for purposes of insurance discrimination; |
| 92 | | * malicious theft of or access to health data (e.g. of a celebrity or politician) for profit or other personal motives; |
| 93 | | * generic threats to data integrity and availability, such as viruses, worms, denial of service attacks etc.; |
| 94 | | * failures in software (due to bugs, incorrect configuration, interoperability failures etc.) causing corruption to data, or incorrect display or computation, resulting in clinical errors. |
| | 82 | |
| | 83 | * 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); |
| | 84 | * 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; |
| | 85 | * inappropriate access by other persons known to the patient, e.g. a by family member; |
| | 86 | * inappropriate access of health data by corporate or other organisations e.g. for purposes of insurance discrimination; |
| | 87 | * malicious theft of or access to health data (e.g. of a celebrity or politician) for profit or other personal motives; |
| | 88 | * generic threats to data integrity and availability, such as viruses, worms, denial of service attacks etc.; |
| | 89 | * failures in software (due to bugs, incorrect configuration, interoperability failures etc.) causing corruption to data, or incorrect display or computation, resulting in clinical errors. |
| 127 | | * 整合性: ヘルス・レコード情報は削除できない。論理的な削除は、データがあたかも削除されたかのように見せる方法で実現される（バージョン制御で実装されている）。 |
| 128 | | * 監査証跡: コンテント・オブジェクト、及びEHRステータスやアクセス制御オブジェクトを含めEHRに対して行われたすべての変更について、ユーザー識別、タイム・スタンプ、理由、オプションとしての電子署名、及び該当バージョン情報による監査証跡が取られる。例外が一つあり、変更者が患者である場合には、シンボリックな識別子を用いることができる(openEHRでPARTY_SELF と呼ぶもの。次の点を参照のこと)。 |
| 129 | | * 匿名性: ヘルス・レコードの内容は、個人識別可能なデモグラフィック情報から分離されている。このことにより、EHRを盗んでも、所有者である患者を識別するための直接の手がかりが得られないといった構成が可能となる (もちろん間接的な手がかりを制御することはもっと難しい)。 識別できるEHRを盗むためには、2つのサーバーからのデータの窃盗、もしくは2台の物理的なコンピュータの窃盗さえもが必要であるが、これはデプロイの構成に依存する。 |
| | 119 | * 整合性: ヘルス・レコード情報は削除できない。論理的な削除は、データがあたかも削除されたかのように見せる方法で実現される（バージョン制御で実装されている）。 |
| | 120 | * 監査証跡: コンテント・オブジェクト、及びEHRステータスやアクセス制御オブジェクトを含めEHRに対して行われたすべての変更について、ユーザー識別、タイム・スタンプ、理由、オプションとしての電子署名、及び該当バージョン情報による監査証跡が取られる。例外が一つあり、変更者が患者である場合には、シンボリックな識別子を用いることができる(openEHRでPARTY_SELF と呼ぶもの。次の点を参照のこと)。 |
| | 121 | * 匿名性: ヘルス・レコードの内容は、個人識別可能なデモグラフィック情報から分離されている。このことにより、EHRを盗んでも、所有者である患者を識別するための直接の手がかりが得られないといった構成が可能となる (もちろん間接的な手がかりを制御することはもっと難しい)。 識別できるEHRを盗むためには、2つのサーバーからのデータの窃盗、もしくは2台の物理的なコンピュータの窃盗さえもが必要であるが、これはデプロイの構成に依存する。 |
| 132 | | * 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). |
| 133 | | * 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). |
| 134 | | * 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. |
| | 124 | |
| | 125 | * 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). |
| | 126 | * 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). |
| | 127 | * 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. |
| 144 | | * 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. |
| 145 | | * 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). |
| 146 | | * 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. |
| 147 | | * 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. |
| | 137 | * 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. |
| | 138 | * 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). |
| | 139 | * 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. |
| | 140 | * 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. |
| | 141 | |
| 149 | | * 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. |
| 150 | | * 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. |
| 151 | | * 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. |
| 152 | | * 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. |
| 153 | | * 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). |
| 154 | | * Certification: a mechanism should be provided to allow a level of trust to be formally associated with user signing keys. |
| 155 | | 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. |
| 156 | | 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. |
| 157 | | |
| | 143 | |
| | 144 | * 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. |
| | 145 | * 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. |
| | 146 | * 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. |
| | 147 | * 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. |
| | 148 | * 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). |
| | 149 | * Certification: a mechanism should be provided to allow a level of trust to be formally associated with user signing keys. |
| | 150 | |
| | 151 | 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. |
| 161 | | Versioning |
| 162 | | 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. |
| 163 | | 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. |
| 164 | | 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. |
| 165 | | Digital Signature |
| 166 | | 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. |
| | 155 | Versioning 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 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. |
| 170 | | 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. |
| 171 | | 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. |
| | 159 | 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. |
| 173 | | 7.3.4 Anonymity |
| 174 | | 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: |
| 175 | | * 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. |
| 176 | | * 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. |
| 177 | | * In every instance of PARTY_SELF; this solution is reasonable in a secure environment, and convenient for copying parts of the record around locally. |
| | 161 | 7.3.4 Anonymity 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: |
| | 162 | |
| | 163 | * 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. |
| | 164 | * 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. |
| | 165 | * In every instance of PARTY_SELF; this solution is reasonable in a secure environment, and convenient for copying parts of the record around locally. |
| | 166 | |
| 182 | | Overview |
| 183 | | 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. |
| 184 | | 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. |
| 185 | | 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. |
| 186 | | 1see e.g. Ross Anderson - "Security in Clinical Information Systems" available at http://www.cl.cam.ac.uk/users/rja14/policy11/policy11.html. |
| 187 | | 2IETF RFC 2440 - http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-18.txt |
| | 171 | 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] |
