HL7 V.2x Privacy Support

1. HL7 V.2x Privacy Support How to bring the Healthcare Enterprise up-to-date with regards to Meaningful Use Privacy requirements

2. 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 adoption • There are no implementation guides for HL7 Version 2 to enable the adoption of confidentiality code and privacy consent within the healthcare enterprise. ‹#›

3. Enterprise Integration and NwHIN Enterprise Enterprise HL7 Version2 HL7 Version2 HL7 Version3 NwHIN Exchange HL7 Version3 HIE ‹#›

4. 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 ‹#›

5. 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 ‹#›

6. Outstanding Issues Need to ascertain original use cases for HL7 v.2Confidentiality 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? ‹#›

7. 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 Gaps Research 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 ‹#›

8. 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 ‹#›

9. 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 domains • Only some HL7 V.3 Confidentiality Codes map to the optional HL7 v.2 Confidentiality Codes ‹#›

10. 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. ‹#›

11. 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. ‹#›

12. 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. ‹#›

13. 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. ‹#›

14. 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.) ‹#›

15. 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. ‹#›

16. 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?” ‹#›

17. HL7 Version 2 Detailed Technical Analysis The following is a detailed analysis of Confidentiality and Privacy support in Hl7 Version

18. ARV Segment: Privacy Consent or Privacy Policy ARV Access Restrictions segment to convey access restrictions in HL7 Version 2 • The 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. ‹#›

19. Access Restriction Codes and Patient Control ARV Access Restrictions segment • A 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. ‹#›

20. 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. ‹#›

21. 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. ‹#›

22. 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. Value Set may be locally defined by each provider ‹#›

23. 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 Privacy Consent Privacy Policy Privacy Policy Sample Policy ‹#›

24. 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 ‹#›

25. Example 2: Use of Confidentiality Code in HL7 v2 Chapter 4: Orders 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 ‹#›

26. Example 3: Use of Confidentiality Code in HL7 v2 Chapter 6: Financial Management • 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 diagnosis • N 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 diagnosis • N the DRG does not contain a confidential diagnosis ‹#›

27. 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. ‹#›

28. Masked Name Type - HL7 Table 0200 ‹#›

29. Example 5: Use of Confidentiality Code in HL7 v2 Chapter 9: Medical Records Management – Transcription • ASSUMPTIONS • Within 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 ‹#›

30. 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 ‹#›

31. 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 ‹#›

32. TXA – Transcription Document Header ‹#›

33. Consent Type ‹#›

34. Consent Status and Bypass Reason ‹#›

35. Consent Disclosure Level& Non-Disclosure Reason ‹#›

36. Non-Subject Consent Reason ‹#›