Input for Policy Advisory Committee
- 1 Input for Policy Advisory Committee - on behalf of Community-Based Collaborative Care Work Group
- 1.1 Background
- 1.2 Composite Privacy Standards
- 1.3 Confidentiality Attributes and Confidentiality Code System
Input for Policy Advisory Committee - on behalf of Community-Based Collaborative Care Work Group
- 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.
- Consent Directive Clinical Document Architecture (CDA) Implementation Guide - a document exchange 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.
Composite Privacy Standards
Consistent Representation of Privacy Policies and Consent Directives
Analysis and reconciliation based on common privacy criteria
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 be 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 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:
- Segment and manage sensitive health information (in support of privacy protection) and
- 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).
Security Work Group has developed a Harmonized Security and Privacy Model to address both the policy and implementation viewpoints. This specification is undergoing final revisions before it will be published as a Draft Standard for Trial Use.
Confidentiality Attributes and Confidentiality Code System
Terminology Issues and Recommendations
Currently the “confidentialityCode” attribute specified in the HL7 Reference Information Model (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 codes 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.1138188.8.131.5228] code system for the following reasons:
- It was not intended to be used with identifiable/actual patient data (as specified in the definition of the value set).
- 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.
Another HL7 Confidentiality value set that requires careful consideration is the ConfidentialityByAccessKind value set, as some of its values 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.
- 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).”
- 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.”
- 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.