HL7 Security WG July Harmonization Proposals

1. HL7 Security WGJuly Harmonization Proposals Kathleen Connor VA (ESC) June 6, 2012

2. HL7 July 2012 Proposals The following proposals were approved with modification during Security WG call June 5, 2012 • Purpose of Use Revisions and Technical Corrections • Confidentiality Vocabulary Technical Corrections • ActPolicyType Revisions and Corrections

3. HL7 Harmonization Proposal July 2012 Security WG Purpose of Use ActReason Code System Add 3 additional PurposeOfUse (POU) codes for: • Program/Plan coverage activities (COVERAGE) • Program/plan enrollment (ENROLLM) • Eligibility verification (ELIGVER) • POU and General POU Value Sets • Add 2 POU codes (ENROLLM & ELIGVER) to the PurposeOfUseValue Set • Add 2 POU codes (COVERAGEand ETREAT) to the GeneralPurposeOfUseValue Set • Deprecate ActHealthInformationPrivacyReason • Redundant and meant to be replaced by ActHealthInformationPurposeOfUseReason •  Fix typo system’s in several POU vocabulary text blocks

4. Confidentiality Vocabulary Technical Corrections • Correction of Confidentiality Concept Domain Definition and Example • Corrected Confidentiality Code “Restricted” Text Block • Corrected Confidentiality Code “Very Restricted” Text Block • Correction of “isImmutable” value set property to “=true” (means that only Security WG can change business use for value set) • Typos, e.g., information’s information’s

5. ActPolicyType Revisions and Corrections • New _ActInformationSensitivityPolicy Code SICKLE (sickle cell) • Inclusion in v: ActInformationSensitivityPolicy Value Set • Correction of ActSensitivityPrivacyPolicyType Concept Domain Text Block • Correction of ActPrivacyLaw Code Text Block • Correction of Typos in EntitySensitivityPolicyType codes DOB, GENDER, LIVARG, MARST, RACE, REL Text Blocks

6. Details ActPolicyType Revisions and Corrections

7. New _ActInformationSensitivityPolicy Code SICKLE (sickle cell)Inclusion in v: ActInformationSensitivityPolicy Value Set LEAF CONCEPT: SICKLE (sickle cell information sensitivity) Description: Policy for handling sickle cell information, which will be afforded heightened confidentiality. Information handling protocols based on organizational policies related to sickle cell information that is deemed sensitive Usage Note: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law rather than or in addition to this more generic code.

8. Correction of ActSensitivityPrivacyPolicyType Concept Domain Text Block • A sensitivity policy is adopted by an enterprise or group of enterprises (a "policy domain") through a formal data use agreement that stipulates the value, importance, and vulnerability of information. A sensitivity code representing a sensitivity policy may be associated with criteria such as categories of information or sets of information identifiers (e.g., a value set of clinical codes or branch in a code system hierarchy). These criteria may in turn be used for the Policy Decision Point in a Security Engine. A sensitivity code may be used to set the confidentiality code used on information about Acts and Roles to trigger the security mechanisms required to control how security principals (i.e., a person, a machine, a software application) may act on the information (e.g., collection, access, use, or disclosure). Sensitivity codes are never assigned to the transport or business envelope containing patient specific information being exchanged outside of a policy domain as this would disclose the information intended to be protected by the policy. When sensitive information is exchanged with others outside of a policy domain, the confidentiality code on the transport or business envelope conveys the receiver's responsibilities and indicates the how the information is to be safeguarded without unauthorized disclosure of the sensitive information. This ensures that sensitive information is treated by receivers as the sender intends, accomplishing interoperability without point to point negotiations.

9. Correction of ActPrivacyLaw Text Block A mandate, obligation, requirement, rule, or expectation characterizing the value or importance of a resource and may include its vulnerability. (Based on ISO7498-2:1989. Note: The vulnerability of personally identifiable sensitive information may be based on concerns that the unauthorized disclosure may result in social stigmatization or discrimination.) Description: Types of Sensitivity policy that apply to Acts or Roles. A sensitivity policy is adopted by an enterprise or group of enterprises (a “policydomainâ€?) policy domain) through a formal data use agreement that stipulates the value, importance, and vulnerability of information. A sensitivity code representing a sensitivity policy may be associated with criteria such as categories of information or sets of information identifiers (e.g., a value set of clinical codes or branch in a code system hierarchy). These criteria may in turn be used for the Policy Decision Point in a Security Engine. A sensitivity code may be used to set the confidentiality code used on information about Acts and Roles to trigger the security mechanisms required to control how security principals (i.e., a person, a machine, a software application) may act on the information (e.g., collection, access, use, or disclosure). Sensitivity codes are never assigned to the transport or business envelope containing patient specific information being exchanged outside of a policy domain as this would disclose the information intended to be protected by the policy. When sensitive information is exchanged with others outside of a policy domain, the confidentiality code on the transport or business envelope conveys the receiver’s receiver’s responsibilities and indicates the how the information is to be safeguarded without unauthorized disclosure of the sensitive information. This ensures that sensitive information is treated by receivers as the sender intends, accomplishing interoperability without point to point negotiations. Usage Note: Sensitivity codes are not useful for interoperability outside of a policy domain without an out-of-band agreement on semantics because sensitivity policies are typically localized and vary drastically across policy domains even for the same information category because of differing organizational business rules, security policies, and jurisdictional requirements. For example, an “employeeâ€?employee sensitivity code (EMPL) would make little sense for use outside of a policy domain. “Tabooâ€? The code “taboo” (TBOO) would rarely be useful outside of a policy domain unless there are jurisdictional requirements requiring that a provider disclose sensitive information to a patient directly. Sensitivity codes may be more appropriate in a legacy system’s system’s Master Files in order to notify those who access a patient’s patient’s orders and observations about the sensitivity policies that apply. Newer systems may have a security engine that uses a sensitivity policy’spolicycriteria directly. The specializable InformationSensitivityPolicy Act.code may be useful in some scenarios if used in combination with a sensitivity identifier and/or Act.title.

10. Correction of Typos in EntitySensitivityPolicyType codes DOB, GENDER, LIVARG, MARST, RACE, REL Text Blocks Policy for handling information related to an information subject’ssubject’s date of birth, which will be afforded heightened confidentiality.Policies may govern sensitivity of information related to an information subject’ssubject’s date of birth, the disclosure of which could impact the privacy, well-being, or safety of that subject.

11. Details Confidentiality Vocabulary Technical Corrections

12. Correct Definition and Example of Confidentiality Concept Domain DEFN=UV=VO=1148-20120324.coremif Lines 4453 <conceptDomain name="Confidentiality"> <annotations> <documentation> <definition> <text> <p>Values that control disclosure of information.appropriate disclosure of  information about this Act, regardless of mood. <p>Privacy metadata indicating the sender's sensitivity classification, which is based on an analysis of applicable privacy policies and the risk of harm that could result from unauthorized disclosure. The confidentiality code assigned by a sender based on the information's sensitivity classification, which may convey a receiver's obligation to ensure that the information is not made available or redisclosed to unauthorized individuals, entities, or processes (security principals) per applicable policies. </p><p><i>Map: </i>Definition aligns with ISO 7498-2:1989 - Confidentiality is the property that information is not made available or disclosed to unauthorized individuals, entities, or processes.</p><p><i>Usage Notes: </i>Confidentiality codes are used as metadata indicating the receiver responsibilities to ensure that the information is not made available or redisclosed to unauthorized individuals, entities, or processes (security principals) per applicable policies.</p> </p> <p> <i>Example:</i> Normal, restricted, substance abuse related very restricted.</p>

13. Corrected Confidentiality Code “Restricted” Text Block LEAF CONCEPT:R (restricted) Description: <p><b>Description: </b>Privacy metadata indicating highly sensitive, potentially stigmatizing information, which presents a high risk to the information subject if disclosed without authorization. May be preempted by jurisdictional law, e.g., for public health reporting or emergency treatment.</p>><p><i>Examples: </i>In the US, this includes what HIPAA identifies as the minimum necessary protected health information (PHI) given a covered purpose of use (treatment, payment, or operations).  Includes typical, non-stigmatizing health information disclosed in an application for health, workers compensation, disability, or life insurance.</p><p><i>Map: </i>Partial Map to ISO 13606-4 Sensitivity Level (3) Clinical Care:   Default for normal clinical care access (i.e. most clinical staff directly caring for the patient should be able to access nearly all of the EHR).   Maps to normal confidentiality for treatment information but not to ancillary care, payment and operations.</p><p><i>Usage Note: </i>This metadata indicates that the receiver may be obligated to comply with applicable, prevailing (default) jurisdictional privacy law or disclosure authorization.</p>

14. Corrected Confidentiality Code“Very Restricted” Text Block LEAF CONCEPT: V (very restricted) Description: <p>Very restricted access as declared by the Privacy Officer of the record holder . Privacy metadata indicating that the information is extremely sensitive and likely stigmatizing health information that presents a very high risk if disclosed without authorization.  This information must be kept in the highest confidence.  </p><p><i>Examples: </i> Includes information about a victim of abuse, patient requested information sensitivity, and taboo subjects relating to health status that must be discussed with the patient by an attending provider before sharing with the patient.  May also include information held under “legal lock” or attorney-client privilege</p><p><i>Map: </i>This metadata indicates that the receiver may not disclose this information except as directed by the information custodian, who may be the information subject.</p><p><i>Usage Note: </i> This metadata indicates that the receiver may not disclose this information except as directed by the information custodian, who may be the information subject.</p>  Previously deprecated definition. The approved new definition was not added.

15. Correction of “isImmutable=true” The original proposal stated (at Page 22) The value sets: v: Confidentiality; x_BasicConfidentialityKind; and v: x_VeryBasicConfidentialityKind should be flagged immutable. Please correct as follows: Line 145366 <valueSet id="2.16.840.1.113883.1.11.10228" name="Confidentiality" isImmutable="true"> Line 145389 <valueSetRef id="2.16.840.1.113883.1.11.16926" name="x_BasicConfidentialityKind"/> isImmutable="true"> Line 145392 <valueSetRef id="2.16.840.1.113883.1.11.19738" name="x_VeryBasicConfidentialityKind"/> isImmutable="true"> Core Principles 5.1.3.5Value Set Immutability At the time a Value Set is defined, the business Use Case or information model design may require that the definition of the Value Set never change. In order to support this, a Value Set has a property called "immutability" which is a Boolean and refers to the Value Set Definition. If TRUE, the Value Set Definition may not be changed in the future. A new Value Set must be created. (There can be no new versions of the Value Set). If FALSE, the Value Set may be changed, and the versioning mechanism will permit traceability of such changes. Note that an immutable intensional definition may still result in an expansion that changes over time if the definition does not explicitly identify the versions of the code systems that it references, thus an isImmutable property set to TRUE will not necessarily make a Value Set expansion unchangeable over time. Therefore, to completely freeze a Value Set expansion, it must have the isImmutable property set to TRUE and the definition must either be Extensional or Intensional where reference is only to specific versions of the underlying code systems.