HL7 CDA R2, Confidentiality Code, and Act Policy Type for DS4P

1. HL7 CDA R2, Confidentiality Code, and Act Policy Type for DS4P Kathleen Connor VA (ESC) February 2012

2. Topics • HL7 Confidentiality Codes • HL7 ActPolicyType Codes • CDA R2 Header Data Elements • CDA R2 support for Confidentiality Code at the header and section levels • How CDA entries can be associated with externally referenced privacy policies, notice of prohibition to redisclose, or consent directives •  C32 and ToC Constraints on CDA capabilities to convey Consent Directives

3. How Confidentiality Codes are Used HL7 v.3 • May be used on HL7 v.3 Act and Role Classes • When HL7 v.3 Artifacts are developed, the use of the Confidentiality Code Attribute is optional • When Confidentiality Code Attribute is used, the standard may restrict the coded values to a subset of all Confidentiality Codes • E.g., CDA restricts Confidentiality Code to value set v_BasicConfidentialityKind • Only Very Restricted (VR), Restricted (R) or Normal (N) codes may be used • See Appendix on Hl7 v.2 Confidentiality Codes

5. Act PrivacyPolicy Type CodeHierarchy • Act Privacy Policy Type • Act Consent Directive • Act Privacy Law • Act US Privacy Law • Act Sensitivity Privacy Policy • Act Information Privacy Policy • Role Information Privacy Policy • Entity Information Privacy Policy

6. How Act Privacy Policy Type Codes are Used • May be used as act.Codes on HL7 v.3 Privacy Policy and Consent Directive Acts • Privacy Policy and Consent Directive Acts in turn are associated by reference, as subject to or as governing another class • Act (e.g., Diagnosis) • Role (e.g., Healthcare Provider) • Entity (e.g., Person who is a Patient) • Can be used to annotate a class as protected information for the policy reason conveyed by the Act Privacy Policy Type Code

7. CDA R2 Header Data Elements • The purpose of the CDA header is to enable clinical document exchange across and within institutions; facilitate clinical document management; and facilitate compilation of an individual patient's clinical documents into a lifetime electronic patient record. • Note that it is not intended for use as a CDA Transmission Wrapper or Document Registry Metadata

9. CDA Support for Consent, Privacy Policy, and Confidentiality External Document at the Entry Level could support reference to Consent Directive, Privacy Policy, and Prohibition against Redisclosure Notification CDA Header Class with Confidentiality Codes VR, R, N CDA Consent Class, which can be used for Privacy Consent Directives CDA Confidentiality Code at Section Level

10. Confidentiality Codes & Consent Directives at CDA Header and Section Levels At CDA Header • Sender must assign a Confidentiality Code • Sender may associate 0..* Consent Directives authorizing actions on the entire document, e.g. • Sender may disclose to Receiver • Receiver may not redisclose • Receiver may use only for purpose of treatment • Dr. Bob, who is a Receiver system user, may not access the document At Section Level • Sender may assign a Confidentiality Code

11. Confidentiality and Consent Directives at CDA Entry Level There are no Confidentiality Code attributes on CDA Entry Level Classes As a work-around, the Sender may reference: • [0..*] Consent Directive or Privacy Policy Type act.Codes and IDs • May embed renderable textual or multimedia description (or reference to a description) of the complete Consent Directive, Privacy Policy, or Prohibition Against Redisclosure, which would reasonably be expected to be displayed to a human reader A user should be able read the embedded text alone, without seeing any of the encoded information, and have no risk of misinterpreting or lacking full understanding of the full content of the External Document Act (e.g., the classCode, moodCode, setID, and versionNumber)

12. How CDA Confidentiality Codes Works with Consent Directives and Provide Policies

13. Nested Confidentiality Codes • Header Confidentiality Code governs the document unless overridden by Confidentiality Code at Section or Entry Level • Section Confidentiality Code may be overridden at the Entry Level by more restrictive referenced Consent Directive or Privacy Policy • Referenced Consent Directive or Privacy Policy at the Entry Level should not be less restrictive than Section Level Confidentiality Code • Two ways to support varying degrees of restriction among Entries in a Section: • Set Section Level Confidentiality Code as restrictive as the most confidential Entry. This approach has less risk but may block access to less confidential Entries in the Section • Set Section Level Confidentiality Code only as restrictive as the least confidential Entry. Apply more restrictive referenced Consent Directive or Privacy Policy to more confidential Entry

14. HITSP C32 • Does not permit use of Consent Class on Header for Data Consent • HITSP Summary Documents Using HL7 Continuity of Care Document (CCD) Component Version:2.1: • Decision: Removed Consent module. Consensus is that if Consents are needed, the actual Consent should be accessed. This 'brief listing of available consents' may infer information that is not actually present

15. Consolidated CDA and Consent Class Consolidated CDA CDAR2_IG_IHE_CONSOL_R1_D2_2011DEC page 59 2.2.11 authorization/consent • The header can record information about the patient’s consent. • The type of consent (e.g., a consent to perform the related serviceEvent) is conveyed in consent/code. Consents in the header have been finalized (consent/statusCode must equal Completed) and should be on file. • The template is not intended for ‘Privacy Consent’. This specification does not address how privacy consents are represented.

16. Work-Around • Kludge to work around C32 constraint on use of Header Consent Class for Privacy Consent Directive: • Sender could reference Consent Directive URI as translation of the Header Level Confidentiality Code • Better solution is to add a metadata code and URI attribute to all RIM Act, Role, and Entity Classes

17. Direct XD* Metadata XDR and XDM for Direct Messaging

18. Direct XD*Document Entry Metadata • This section lists the metadata associated with the content of the message (called document by IHE). • The following table lists each of the applicable metadata elements, the optionality specified in the IHE XDS specification and the adjusted optionality defined by the Minimal Metadata specification. • The table also gives a few details regarding conformance of the value of the metadata element

19. Direct XD*Submission Set Metadata • This section lists the metadata associated with the set of content of the message (called submission set by IHE). Note that IHE allows multiple documents (content parts) and this set of metadata groups this set of documents and gives metadata that is common to all. • The following table lists each of the applicable metadata elements, the optionality specified in the IHE XDS specification and the adjusted optionality defined by the Minimal Metadata specification. The table also gives a few details regarding conformance of the value of the metadata element.

20. XD* Metadata Derivation Some XD* Wrapper and Document Set Metadata may be derived from CDA Payload • author: “If supplied, MUST indicate the document's author, which may be different from the message sender” • class, typeCode, and contentType codes • uniqueID: “Implementations SHOULD use a unique ID extracted from the content, if a single such value can be determined. If not, implementations SHOULD use a UUID URN, generated for the transaction. This value must be different from the uniqueId specified on the Submission Set” • healthcareFacilityTypeCode • practiceSettingCode • patientID

21. Problematic Metadata • Some Metadata codes from HITSP reveal protected information • healthcareFacilityTypeCode • practiceSettingCode • classCode / typeCode • Not clear that some of the XD* Metadata can be directly derived from CDA • Need guidance to ensure consistent approach to deriving Metadata from payload (CDA and messages – e.g., X12 275 and Claims Attachment response to Payer for HITECH, HL7 v.2 Lab) to protect confidential information especially when exchanged through an intermediary

22. healthcareFacilityTypeCode • When available, implementations SHOULD draw values from HITSP C80, version 2.0.1, table 2-146. Implementations SHOULD populate mapped by configuration to sending organization • Hospital-psychiatric • Hospital outpatient mental health center • Free-standing mental health center • Sexually transmitted disease health center • Substance abuse treatment center

23. practiceSettingCode / Clinical Specialty • This is the code representing the clinical specialty of the clinician or provider who interacted with, treated, or provided a service to/for the patient • The value set used for clinical specialty has been limited by HITSP to the value set reproduced below in Table 2-149 Clinical Specialty Value Set Definition • Adult mental illness • Psychiatry • Psychotherapy

24. classCode / typeCode • When available, implementations SHOULD draw values from HITSP C80, version 2.0.1, table 2-144 • Counseling note • If value set extended, need to be aware that the Document Class codes on Wrapper may reveal protected information in payload

25. Where Metadata is found in CDA Header Intended Recipient Author

26. practiceSetting/Clinical Specialty is an AssignedEntity Role Code, which may not map to HITSP SNOMED value set Document Class Type – use LOINC codes from HITSP value set healthcareFacilityTypeCode – uses HL7 ServiceDeliveryLocationRoleType, Not HITSP C80 SNOMED value set

27. Patient

28. Act Privacy Policy Type Code System & HL7 v2 Confidentiality Codes Appendix

43. Use of Confidentiality Code in HL7 v2 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. Need to Harmonize with v.3 Confidentiality Codes and Act Privacy Policy Type Codes

44. APPENDIX C

45. C80 LOINC Document TypeTable 2-144 Document Class Value Set Definition

46. C83 Table