Direct XD* Envelop Metadata for DS4P

1. Direct XD* Envelop Metadata for DS4P Kathleen Connor VA (ESC) February 2012

2. DIRECT Overview and XD* • Direct Project includes support for trading partners capable of exchanging and registering payloads wrapped with XD* Metadata • The XD* Metadata may be derived from the payload • Some Metadata may be revealing of protected payload information • DS4P, Query Health, and Direct Projects should avoid using Metadata that reveals what is intended to be concealed from unauthorized users, including intermediaries, while ensuring that appropriate routing and patient matching information is available on the envelope

3. XDR and XDM for Direct Messaging • This specification discusses the application of XDR and XDM to the direct messaging environment and the interaction between the primary Direct Project environment, which uses SMTP and RFC 5322 to transport and encode healthcare content, and the XDR and XDM specifications.This specification defines: • Use of XD* Metadata with XDR and XDM in the context of directed messaging • Additional attributes for XDR and XDM in the context of directed messaging • Issues of conversion when endpoints using IHE XDR or XDM specifications interact with endpoints utilizing SMTP for delivering healthcare content. • To view or edit the current wiki-text working version of the document, click here DIRECT Overview

4. CDA Annotated with XD* Data Sources & Support for Privacy/Consent

5. 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

6. 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.

7. 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

8. 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

9. Where Metadata is found in CDA Header Author and Intended Recipient may reveal protected information. Recommend using more generic codes for Role if necessary Intended Recipient Author

10. Document Type, Practice Setting, and Facility Type may reveal Protected InformationRecommend: Use more Generic codes for Protected Types 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

11. 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

12. 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

13. 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

14. Patient Information may be Confidential Recommend: Limit Wrapper Metadata to minimum needed for accurate Patient Matching Patient