Input for Policy Advisory Committee

Input for Policy Advisory Committee - on behalf of Community-Based Collaborative Care Work Group

Background

HL7 Community Based Collaborative Care Work Group (CBCC WG) had developed several standards in support of electronic privacy policies and consent directives. The contents and semantics are standardized by two recent specifications that include US-based requirements for privacy policy and consent directives:

1. Data Consent HL7 Version Messages Version 1.0 - a messaging method for exchanging consent data consent options based primarily on use cases supplied by Canadian stakeholders.
2. Composite Privacy Consent Directive DSTU – a standard model to describe electronic/interoperable Privacy Policies and Consent Directives. This standard was developed in collaboration with Security WG.
3. Consent Directive Clinical Document Architecture (CDA) Implementation Guide - a document exchnage standard based on the Composite Privacy Consent Directive DSTU. This standard was developed in collaboration with Security WG.

Note: These two specifications are referred collectively as the “Composite Privacy standards” for the rest of this document.

Previously approved specifications (“Data Consent Version 1.0”) have been adopted successfully in Canada. The approval of the Composite Privacy standards introduced support for US-based privacy policies and privacy consent directives to support PHRs and empower consumers. These Composite Privacy standards specify the common contextual attributes of health information that determine which health information is deemed “sensitive” in the context of a specific privacy policy. Contextual information such as the diagnosis/problem (e.g. substance abuse, mental health), the payment method (e.g. cash payments), the type of information (e.g. genomics), the insurance program (e.g. private vs. public insurance, Medicaid) is explicitly stated in privacy policies.

Composite Privacy Standards

Consistent Representation of Privacy Policies and Consent Directives

The Composite Privacy Consent standards are based on the premise that more than one privacy policy may be applicable in any organization. HIPAA Privacy provides the floor, or baseline protection on which other policies are layered (e.g. Genetic Information Non-Discrimination Act of 2008- GINA, Confidentiality of Alcohol and Drug Abuse Patient Records – 42 CFR Part 2, ARRA HITECH Act Cash Payments, state law for HIV and STD, state law regarding the confidentiality provided to Medicaid patients and other vulnerable populations). The Composite Privacy standards define the common elements across all these policies in a standard-based and interoperable form that is implementation neutral. Therefore whether the standard is used to author privacy policies or privacy consent directives, the criteria used to specify sensitive information will be consistent across policies and privacy consents.

Analysis and reconciliation based on common privacy criteria

The HL7 Composite Privacy standards allows healthcare providers to automatically delineate sensitive information including contextual criteria specified by a privacy policy and/or privacy consent directive based on a standard set criteria. The consistent privacy criteria specified by Composite Privacy standards enables both analysis and reconciliation of different policies based the standard set of criteria (e.g. information type, related diagnosis, population type, payment method) regardless of implementation. For example if a state policy specifies mental health information is sensitive and a separate policy exists to protect the privacy of Medicaid patients extending sensitivity to HIV and Sexually Transmitted Disease information, then if these policies were available in a standard form, the policies could be automatically analyzed and the resulting reconciled policy would deem that a Medicaid patient’s mental health, HIV, and STD information are all sensitive and thus will not be exchanged with other organizations without the patient consent.

Support for a variety of computer security technologies

Simply by describing privacy policies and privacy consent directives using standard-based, computable criteria HL7 Composite Privacy standards enable computer systems and business rules engines to distinguish sensitive data and manage it appropriately. Furthermore, these standards promote the adoption of established technology approaches (e.g. access control, digital rights) to manage sensitive healthcare information by bridging the gap between the health information representation and the privacy policies that apply. The ability to represent privacy policies and privacy consent directives in electronic and interoperable form is especially important when policies have to compared and reconciled across jurisdictions. It is also beneficial to have a direct and computable link between the policy and the information exchanged between healthcare providers across a nationwide network or served directly from a Personal Health Record (PHR) to providers or research and marketing purposes by allowing patients to specify complex criteria describing the type of information that should be protected. This empowers patients/consumers and ensures trust in the overall privacy of interconnected information systems.

A comprehensive approach to privacy

The Composite Privacy Consent standards are based on the premise that more than one privacy policy may be applicable in any organization: HIPAA Privacy provides the floor, or baseline protection on which other policies are layered (e.g. Genetic Information Non-Discrimination Act of 2008- GINA, Confidentiality of Alcohol and Drug Abuse Patient Records – 42 CFR Part 2, ARRA HITECH Act Cash Payments, state law re: HIV, STD, state law regarding the confidentiality Medicaid patients). The Composite Privacy standards define the common elements across all these policies in a standard and interoperable form that is implementation neutral.

Future Work

The CBCC WG recently approved a new Semantic Health Information Performance and Privacy Standard (SHIPPS) project intended to identify and define the metadata and data quality (structured encoded data) necessary to:

1. Segment and manage sensitive health information (in support of privacy protection) and
2. Enable real-time performance evaluation: the ability to automate the use of EHR systems data for the purposes of quality outcomes measurement and performance

It is important that healthcare providers invest in information systems (e.g. Electronic Health Record Systems) that are able to create structured and standard-encoded information ready to be processed for a variety of purposes (e.g. to identify sensitive information according to a specific policy, to compute real-time quality measures).

Confidentiality Attributes and Confidentiality Code System

HL7 specifies that information artifacts represented using the HL7 Reference Information Model may include a confidentiality attribute intended to specify whether an information object is sensitive or not. For example a clinical document may be deemed sensitive if its content is identified by a specific privacy policy. Sensitivity is an intrinsic property of an information artifact and it is determined based on privacy policies. The confidentiality attribute may be added to the information exchange envelope to specify how participants in an information exchange should handle information intended to be protected based on privacy policy. For example, sensitive information may have to be encrypted and its content must be secured against tampering during transport.

Terminology Issues and Recommendations

Currently the “confidentialityCode” attribute specified in the HL7 Reference Information RIM is ambiguous as it attempts to specify both the sensitivity of health information and how that health information may be accessed by users. According to the HL7 RIM, the definition of the confidentiality code “needs work in particular to help distinguish and identify the relationship between the types of concepts that it conveys and how best to encode and communicate them with this one attribute.” Therefore, implementers should use the confidentiality code as the single basis of determining if information is sensitive, and it is a useful means of conveying that the data is protected by policy. In other words, an information object is marked as sensitive using confidentiality code only after the system determines that its content is intended to be protected according to privacy policies (e.g. sensitive diagnosis, vulnerable population, self/cash pay for services). Clearly this level of automation is only possible with structured and standard-encoded information.

Confidentiality codes for information exchange

It is conceivable and desirable to rely on confidentiality code while health information is in transit and triggers specific security mechanisms (e.g. transport level security – encryption) for sensitive information that may not be needed for routine (non-sensitive) information. Therefore, as a matter of best practice from a privacy stand-point, implementers of EHRS and PHR system should avoid the HL7 ConfidentialityByInfoType value set specified in the Confidentiality [2.16.840.1.113883.1.11.10228] code system for the following reasons:

1. It was not intended to be used with identifiable/actual patient data (as specified in the definition of the value set).
2. The codes HIV-for HIV related, ETH-for Substance Abuse related, PSY-for psychiatry related, and SDV-for Sexual and domestic violence related would reveal too much of the nature of the sensitive information intended to be protected. If this code is used in a transport envelope or clinical document registry it would inadvertently disclose information to unauthorized users. It would be preferable that data related to sensitive conditions simply be marked sensitive without specifying the condition.
3. These codes are used as short-hand to reference the privacy policy dealing with certain conditions or problems. Enumerating these policies in a code set is not scalable as new privacy policies are introduced overtime. In the US this value set would have be extended to include sickle cell anemia and sexually transmitted diseases and it would have to be continuously updated as new policies are added.

Another HL7 Confidentiality value set that requires careful consideration is ConfidentialityByAccessKind value set because some of its value explicitly do not allow for use with identifiable/actual patient data and implementers may assign them erroneously. This value set should be refactored to separate codes that are applicable to patient information from those that only apply to other types of information. It is also specific to some “service” – presumably a medical service delivered to a consumer.

1. Some codes in this value set refer not to an intrinsic sensitivity of the information object but to an external policy. Therefore this would be better addressed as a reference to that uniquely identified policy rather than a code:
   • “D” specifies that “only clinicians may see this item”.
   • “I” specifies that the information system may allow access “only to individual persons who are mentioned explicitly as actors of this service and whose actor type warrants that access (cf. to actor type code).”
2. Some codes are explicitly not allowed for patient information
   • “B” refers to “business secret” and should not be used for patient information: “However, no patient related information may ever be of this confidentiality level.”
   • ”L” – low confidentiality code – is explicitly prohibited for patient information: "No patient record item can be of low confidentiality. However, some service objects are not patient related and therefore may have low confidentiality.”
3. As it stands today, this value set represents an incomplete list of “hardcoded” access control policies limiting access to information based on a broad categories of structural and functional user roles. These policies could be implemented very differently.

[category:CBCC]