Input for Policy Advisory Committee

Input for Policy Advisory Committee

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. Composite Privacy Consent Directive DSTU – a standard model to describe electronic/interoperable Privacy Policies and Consent Directives
2. Consent Directive Clinical Document Architecture (CDA) Implementation Guide - based on the Composite Privacy Consent Directive DSTU

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, the baseline protection, on which it are layered other policies (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 Medicaid patients or other vulnerable populations). The Composite Privacy standards defines the common elements across all these policies in a standard and interoperable form that is implementation neutral. Therefore if the standard is used to author privacy policies or consent directives it will ensure that the criteria used to specify sensitive information are consistent across policies and 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 consent directive based on a standard set criteria. The consistent privacy criteria specified by Composite Privacy 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 a mental health information is sensitive and a separate policy may be intended to protect the privacy of Medicaid patients and thus extend sensitivity to information related to HIV and Sexually Transmitted Diseases. 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 is sensitive and it will not be exchanged with other organizations unless the patient consents.

Support for a variety of computer security technologies

Simply by describing privacy policies and 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 in healthcare by bridging the gap between the health information representation and the privacy policies that apply. The ability to represent privacy policies and consent directives in electronic and interoperable form is especially important when policies have to compared and reconciled across jurisdictions. If is also beneficial to have direct and computable link between the policy to the information between healthcare providers across a nationwide network or served directly by a Personal Health Record (PHR) to providers, research, marketing or marketing by allowing patients to specify complex criteria defining information to be shared. This empowers patients/consumer 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, the baseline protection, on which it are layered other policies (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 defines 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 contents 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 may be added to the information exchange envelope to specify

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, the implementers should use the confidentiality code as the single basis of determining if information is sensitive but it is 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 contents 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 trigger specific security mechanisms (e.g. transport level security – encryption) for sensitive information that may not be needed for routine information. Therefore, as a matter of best practice from a privacy stand-point, implementers of EHRS and PHR system should avoid HL7 ConfidentialityByInfoType value set specified in the Confidentiality [2.16.840.1.113883.1.11.10228] code system.

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 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 condition 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 that requires careful consideration is ConfidentialityByAccessKind value set because some of its value are explicitly not allow for identifiable/actual patient data and implementers may assign them erroneously. This value set should be refactored to separate the codes that are applicable to patient information to those that are only applicable 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 need 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 represent 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.