HOW TO BRING THE HEALTHCARE ENTERPRISE UP-TO -DATE WITH REGARDS

TO MEANINGFUL USE PRIVACY REQUIREMENTS

HL7 V.2x Privacy Support

‹#›

Overview

HL7 Version 2.x is still the major standard for integrating healthcare enterprises and this will not change with Meaningful Use

HL7 Version 3.0 Confidentiality Code System used by HITSP, NwHIN Exchange, and Direct Metadata

Consistency between privacy/confidentiality support in HL7 Version 2 and 3 have not been a priority Due to lack of adoption of privacy in the current enterprise

environment pre-Meaningful Use adoptionThere are no implementation guides for HL7 Version 2 to

enable the adoption of confidentiality code and privacy consent within the healthcare enterprise.

‹#›

Enterprise Integration and NwHIN

HL7 Version2

HL7 Version2

NwHIN Exchange

Enterprise

Enterprise

HIE

HL7 Version3

HL7 Version3

‹#›

Problem

HL7 Version 2 still the standard for integrating the healthcare enterprise

Meaning Full use requires that intra-enterprise privacy protection to be improved

Across the HIE or NwHIN we need to support the intended confidentiality specified by the PHI source/author

How do we ensure the intended privacy metadata in the enterprise

‹#›

Confidentiality Codes and Privacy Protection

Confidentiality Codes are used for protecting the privacy of health information exchanged using a variety of standards: HL7 v.2 messages, typically for use within an

organization HL7 v.3 messages, for ORG, Pt2Pt, and federated

exchange HL7 CDA profiles, for All IHE specifications (XD* metadata), for All IHE CDA profiles, for All

‹#›

Outstanding Issues

Need to ascertain original use cases for HL7 v.2 Confidentiality and privacy consent related segments, data elements, and vocabulary

Are these artifacts being implemented and used?

If not, are there alternative mechanisms to support confidentiality and consent, especially where there are policy mandates?

Is there a need to “round trip” confidentiality and consent support from HL7 v2 intra-enterprise systems to HL7 v3 inter-enterprise exchanges?

‹#›

Potential Action Items

Documenting the original use cases for v.2 Confidentiality and privacy consent related segments, data elements, and vocabulary

Survey implementers for evidence of whether, and if so, how these v.2 artifacts are used in practice

Survey alternative mechanisms used by v.2 implementations to support confidentiality and privacy consent

Document GapsResearch the need for round tripping confidentiality and

consent support between HL7 v.2 intra-enterprise systems and HL7 v.3 inter-enterprise federated and direct exchanges

Map to HL7 v.3 use cases and artifacts

‹#›

Harmonization & Refactoring

CBCC Confidentiality Code Refactoring Project intends to rationalize current HL7 v.3 Confidentiality Codes

V.3 Confidentiality Codes set structure includes a number of conceptual axes (Purpose of Use, Access Control, Sensitivity of the data ) that may need to be disambiguated and removed if redundant, misused, or lack basis in real use cases

‹#›

Harmonization & Refactoring (continued)

HL7 v.2 Confidentiality Codes are marked as optional and may be redefined by each organization A problem for interoperability across enterprise and

affinity domainsOnly some HL7 V.3 Confidentiality Codes map

to the optional HL7 v.2 Confidentiality Codes

‹#›

HL7 V.2 Consent Terms and Concepts -1

The following is a list of concepts included in a privacy consent as specified in the HL7 Version 2 standards.

Consent Background: Typically consent must be “informed” consent. This means that

the consenting individual must understand and appreciate the implications of what they are consenting to. Most consent processes involve providing background material describing the reasons for the proposed service, expected benefits and potential risks. It is important to have a record of what information was presented to the subject at the time of consent.

Consent Bypass Reason: There may arise situations in which an action must be performed without

patient consent (i.e., retrieving an unconscious patient’s drug history, performing life saving surgery, etc.). This field indicates the rationale for accessing information without obtaining the required consent.

‹#›

HL7 V.2 of Consent Terms and Concepts -2

Consent Decision Date/Time: Related to the consent decision, there also needs to be a record of

the time the subject actually made their consent decision.Consent Disclosure Level: Identifies whether the subject was provided with information on the

full background information on the procedure the subject is giving consent to; i.e., has all information needed for ‘informed’ consent been provided.

Consent Discussion Date/Time: For informed consent, a knowledgeable person must discuss the

ramifications of consent with the subject. In some instances, this discussion is required to take place prior to the provision of consent.

This ensures that the subject has sufficient time to consider the ramifications of their decision. To ensure that guidelines are followed, it is imperative to record when the consent information was initially discussed with the subject.

‹#›

HL7 V.2 of Consent Terms and Concepts -3

Consent Effective Date/Time: Not all consents take effect at the time the consent decision is made. They may not

become effective for some time, or in certain circumstances they may even be retroactive. Use this field to record the effective time.

Consent End Date/Time: For most programs requiring voluntary participation, the decision to participate is

not final and therefore may be revoked in the future. Therefore, when a patient makes the decision to revoke their consent, the date and time on which the decision was made must be recorded in order to provide a complete history of the consent.

Alternatively, the initial consent may only have been granted for a limited period of time (i.e., 24 hours, 1 week, 1 year). If Consent End Date/Time is null, this should be interpreted as 'indefinite.'

Consent Form ID: Some institutions may have a set of pre-defined consent forms. Identifying the

specific form identifies the details the subject is consenting to, as well as what information is on the form.

‹#›

HL7 V.2 of Consent Terms and Concepts -4

Consent Mode: The manner in which consent can be given may vary greatly within a

specific program, from program to program, or from organization to organization. Therefore, the standard must allow applications to identify how consent was obtained (i.e., verbally, written, etc.).

Consent Non-disclosure Reason: Identifies why information was withheld from the patient (i.e., telling

the patient may cause a worse outcome than performing the procedure).

Consent Segment: The issue of patient consent has become more important, particularly

in the tracking of consent for the release of or exchange of information. The pieces of information recorded when dealing with a patient consent tend to be similar, regardless of the purpose of the consent. This segment combines these pieces of information so that they can be used for consents of any type.

‹#›

HL7 V.2 of Consent Terms and Concepts -5

Consent Status: Consent can be pending (subject hasn’t been asked yet), given, refused,

revoked or even completely bypassed. Consent Status identifies what the status of a subject’s consent is (or was at a given point in time).

Consent Text: When recording consents electronically it is important to know the specific text that

was presented to the consenting person.Consent Type: In concert with giving consent, some programs may allow patients to request

varying degrees of participation in a given program. I.e., if a consent program relates to a patient’s entire medical record being available online they might have the opportunity to only reveal certain portions of that history, such as the drug history only.

Informational Material Supplied Indicator: As part of the informed consent process, additional material in the form of

pamphlets, books, brochures, videos, etc., may be provided to the patient. An indication of whether this has been done is required. (Details on the materials provided will be sent using a separate segment.)

‹#›

HL7 V.2 of Consent Terms and Concepts -6

Subject Competence Indicator: One of the issues involved in informed consent is whether the

subject is judged to be competent to provide consent on their own behalf. Factors involve age, mental capacity, and current state of health/awareness. A professional judgment about whether the subject is deemed competent must be made and recorded.

Restricted: A confidentiality status in which access to a document has

institutionally assigned limitations.Subject-imposed Limitations: At the time of consent, the subject may wish to make

modifications or add limitations to their consent. These modifications and limitations must be recorded.

‹#›

HL7 V.2 Definition of Consent Terms and Concepts-6

Subject-specific Background Text: The reasons, expected benefits and risks may vary from subject to

subject. It may be necessary to inform the subject of background information that only applies to their particular circumstance.

Subject-specific Consent Text: Sometimes consent forms have areas where details of the

procedure or information distribution that are specific to a given consent instance are recorded, i.e., a variation on a common procedure, or an explicit listing of documents to be released.

As this is part of the consent document, it needs to be recorded. It is helpful to keep this information separate from the standard ‘template’ consent text, as in most circumstances people viewing the consent will want to know “What’s different from usual?”

THE FOLLOWING IS A DETAILED ANALYSIS OF CONFIDENTIALITY AND PRIVACY

SUPPORT IN HL7 VERSION

HL7 Version 2 Detailed Technical Analysis

‹#›

ARV Segment: Privacy Consent or Privacy Policy

ARV Access Restrictions segment to convey access restrictions in HL7 Version 2The ARV segment is used to communicate the

requested/required type of access restrictions from system to system, at both the person/patient and the encounter/visit level.

Examples: A person/patient may have the right to object to disclosure of

any or all of his/her information. In addition, the patient may request that protected information not be disclosed to family members or friends who may be involved in their care or for notification purposes.

A jurisdiction or organization may have certain privacy policies that are represented as restrictions (ARV) and accompany the relevant patient records.

‹#›

Access Restriction Codes and Patient Control

ARV Access Restrictions segmentA patient may have the right to opt out of being

included on facility directories.In an international context, a physician may be

culturally obligated to protect the patient's privacy.Any "opt-in" or "opt-out" restrictions are

communicated in ARV-3 - Access Restriction Value. This segment replaces PD1-12 and PV2-22, which have been

deprecated in V2.6. The ARV segment is optional and is sent after the PV1/PV2

segments to describe access restrictions associated with that specific encounter.

‹#›

Confidentiality Code Use Notes in HL7 V2 (1)

The individual system security may want to utilize the Access Restriction Value along with the Access Restriction Reason (and/or with the Confidentiality Code from another segment, e.g., OM1-30 or other data) in order to implement the appropriate type of protection for the person, patient, visit and/or visit data. Each system has the flexibility to incorporate/map the access

values into their security system appropriately; the actual implementation for access to protected data is determined by the individual system.

The Access Restriction Values supported by an enterprise/system would be defined and determined by that organization.

‹#›

Confidentiality Code Use Notes in HL7 V2 (2)

It is expected that these access restriction values would be utilized in combination with other system security information (e.g., patient locations, user department, caregiver-patient relationships, other access restriction parameters) to determine user access.

System implementers should carefully control access to the restriction codes and values, as they themselves hold sensitive information.

‹#›

Field ARV-3 Access Restriction Value (CWE) 02145

Definition: This field specifies the information to which access is restricted. This access may be restricted at a field level by employing the specific HL7 field identifiers or may be otherwise determined by user-defined coded values.

User-defined Table 0717 - Access Restriction ValueValue Description CommentALL All  DEM All demographic data  LOC Patient Location  PID-7 Date of Birth  

PID-17 Religion  HIV HIV status and results  STD Sexually transmitted diseases  PSY Psychiatric Mental health  DRG Drug  SMD Sensitive medical data  NO None  OO Opt out all registries (HIPAA)  OI Opt in all registries (HIPAA)  

Value Set may be locally defined by

each provider

3.1.1.0 ARV-3 Access Restriction Value (CWE) 02145

‹#›

ARV-4 Access Restriction Reason (CWE) 02146

Definition: This field is used to convey the reason for the restricted access. Repeat of the Access Restriction Reason is allowed to accommodate communication of multiple reasons for an access restriction

User-defined Table 0719 - Access Restriction Reason Code

Value Description CommentPAT Patient Request  PHY Physician Request  REG Regulatory requirement  ORG Organizational policy or

requirement 

EMP Employee of this organization  DIA Diagnosis-related  VIP Very important person or celebrity  

Privacy Consent

Privacy Policy

Privacy Policy

Sample Policy

‹#›

Example 1: Use of Confidentiality Code use in HL7 v2

Chapter 8: Master Files

OM1-30 Confidentiality Code (CWE) 00615 Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^

<Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)> ^ <Second Alternate Identifier (ST)> ^ <Second Alternate Text (ST)> ^ <Second Name of Alternate Coding System (ID)> ^ <Second Alternate Coding System Version ID (ST)> ^ <Coding System OID (ST)> ^ <Value Set OID (ST)> ^ <Value Set Version ID (DTM)> ^ <Alternate Coding System OID (ST)> ^ <Alternate Value Set OID (ST)> ^ <Alternate Value Set Version ID (DTM)> ^ <Second Alternate Coding System OID (ST)> ^ <Second Alternate Value Set OID (ST)> ^ <Second Alternate Value Set Version ID (DTM)>

Definition: This field contains the degree to which special confidentiality

protection should be applied to the observation. For example, a tighter control may be applied to an HIV test than to a

CBC. Refer to User-defined Table 0177 - Confidentiality code for suggested values

‹#›

Example 2: Use of Confidentiality Code in HL7 v2

Chapter 4: Orders

28     CWE O   0177 00615 Confidentiality Code

User-defined Table 0177 - Confidentiality code

Value Description CommentV Very restricted  R Restricted  U Usual control  

EMP Employee  UWM Unwed mother  VIP Very important person or

celebrity 

PSY Psychiatric patient  AID AIDS patient  HIV HIV(+) patient  ETH Alcohol/drug treatment

patient 

Definition: This field contains information about the level of security and/or sensitivity surrounding the order (e.g., highly sensitive, not sensitive, sensitive, etc.). Refer to HL7 Table 0177 – Confidentiality Code for allowed values. The specific treatment of data with a particular confidentiality level is subject to site-specific negotiation.

Value Set may be locally defined by

each provider

‹#›

Example 3: Use of Confidentiality Code in HL7 v2 Chapter 6: Financial Management

18 1..1   ID O   0136 00767

Confidential Indicator

DG1-18 Confidential Indicator (ID) 00767

Definition: This field indicates whether the diagnosis is confidential. Refer to HL7 table 0136 - Yes/no Indicator for valid values.Y the diagnosis is a confidential diagnosisN the diagnosis does not contain a confidential diagnosis

DRG-10 Confidential Indicator (ID) 00767

Definition: This field indicates if the DRG contains a confidential diagnosis. Refer to HL7 table 0136 - Yes/no Indicator for valid values.Y the DRG contains a confidential diagnosisN the DRG does not contain a confidential diagnosis

‹#›

Example 4: Use of Confidentiality Code in HL7 v2 Chapter 16: eClaims

EHC^E12 – Request Additional Information (event E12) Interpretative Rule: Patient Consent. If Patient Consent in the

RFI segment is marked "Y" (Yes) the Payer is signifying possession of proof of patient consent for release of confidential information.

EHC^E13 – Additional Information Response (event E13) Informative Rule: Document Confidentiality Status on TXA. When

this optional field is completed it indicates that the Payer is to restrict access to the attached document according to the Payer's established policies and/or in accordance with prior business agreements between the Provider and Payer.

PSL-21 Restricted Disclosure Indicator (ID) 01975

Definition: Set to "Yes" if information on this invoice should be treated with increased confidentiality/security. Refer to User-defined Table 0532 – Expanded Yes/No Indicator for suggested values.

HL7 Table 0532 - Expanded yes/no indicatorValue Description Comment

Y Yes  N No  NI No Information No information whatsoever can be inferred from this exceptional value.

This is the most general exceptional value. It is also the default exceptional value

NA not applicable No proper value is applicable in this context (e.g., last menstrual period for a male)

UNK unknown A proper value is applicable, but not knownNASK not asked This information has not been sought (e.g., patient was not askedASKU asked but unknown Information was sought but not found (e.g., patient was asked but didn't

knowNAV temporarily

unavailableInformation is not available at this time but it is expected that it will be available later

NP not present Obsolete as of v2.7.

‹#›

Masked Name Type - HL7 Table 0200

MSK Masked There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information. Note: using this null flavor does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.

1

‹#›

Example 5: Use of Confidentiality Code in HL7 v2 Chapter 9: Medical Records Management – Transcription

ASSUMPTIONSWithin this section, we have created a single

message whose contents vary predicated on the trigger event. The following assumptions are made when the Medical Document Management (MDM) message is used:

The application system is responsible for meeting all legal requirements (on the local, state, and federal levels) in the areas of document authentication, confidentiality, and retention.

HL7 v.27 Chapter 9.5 page 10

‹#›

Transcription Triggering Event

These triggering events are mainly associated with documents or entries that will be or have been transcribed. The types and appearance of the transcribed documents can vary greatly within a healthcare organization and between organizations.

HL7 v.27 Chapter 9.6 page 11

‹#›

MDM/ACK - Document Status Change Notification (Event T03)

This is a notification of a change in a status of a document without the accompanying content.

Scenario: A document is authenticated. Notification is sent to the chart tracking system and is used to update the document status from pre-authenticated to authenticated or legally authenticated.

A change in any of the following independent status characteristics would cause a message to be sent:

Completion Status Confidentiality Status

HL7 v.27 Chapter 9.6.3 page 12

‹#›

TXA – Transcription Document Header

HL7 Table 0272 - Document Confidentiality Status

Definition: This is an optional field which identifies the degree to which special confidentiality protection should be applied to this information. The assignment of data elements to these categories is left to the discretion of the healthcare organization.

Value Description Comment

V Very restricted  

R Restricted  

U Usual control  

‹#›

Consent Type

User Defined Table 0496 - Consent TypeDefinition: This field describes what the subject is consenting to, i.e., what type of service, surgical procedure, information access/release or other event. (Below are only information related types)

Value Description Comment

001Release of Information/MR / Authorization to Disclosure Protected Health Information

Release of Info/ Disclosure

041Disclosure of Protected Health Information to Family/Friends

Release of Info/ Disclosure

079 Med, Psych, and/or Drug/AlcoholRelease of Info/ Disclosure

102 Psychiatric Information During Hospital StayRelease of Info/ Disclosure

103 Public Release of InformationRelease of Info/ Disclosure

110Request to Restrict Access/Disclosure to Medical Record/Protected Health Information

Release of Info/ Disclosure

111 Request for Remain AnonymousRelease of Info/ Disclosure

136 VideotapeRelease of Info/ Disclosure

‹#›

Consent Status and Bypass Reason

HL7 Table 0498 - Consent StatusDefinition: Identifies why the subject’s consent was not soughtValue Description Commen

tA Active – Consent has been granted  L Limited – Consent has been granted with limitations  R Refused – Consent has been refused  P Pending – Consent has not yet been sought  X Rescinded – Consent was initially granted, but was

subsequently revoked or ended. 

B Bypassed (Consent not sought)  User Defined Table 0499 - Consent Bypass Reason

Definition: Identifies why the subject’s consent was not sought

Value Description Comment

E Emergency  

PJ Professional Judgment  

‹#›

User Defined Table 0501 - Consent Non-Disclosure ReasonDefinition: Identifies why the subject did not receive full disclosure.

Value Description CommentE Emergency  

RX Rx Private  PR Patient Request  

HL7 Table 0500 - Consent Disclosure LevelDefinition: Identifies how much information was disclosed to the subject as part of the informed consent process.

Value Description CommentF Full Disclosure  P Partial Disclosure  N No Disclosure  

Consent Disclosure Level& Non-Disclosure Reason

‹#›

Non-Subject Consent Reason

User Defined Table 0502 - Non-Subject Consenter ReasonDefinition: Identifies how much information was disclosed to the subject as part of the informed consent process.

Value Description CommentMIN Subject is a minor  NC Subject is not competent to

consent 

LM Legally mandated