Data+Segmentation+for+Privacy+Consensus

include component="page" wikiName="siframework" page="Data Segmentation Header"

Data Segmentation for Privacy Consensus
This consensus page is used to capture specific recommendations and findings for each of the Tiger Teams and the standards analysis activities that were conducted in the toc

Consensus Statement
//The summary table below highlights key areas of decision reached by the S&I Framework Data Segmentation for Privacy workgroups on major issues encountered in standards harmonization. The table of contents shown on the right also allows the reader the opportunity to jump to specific sections of interest://
 * **Implementation Area of Analysis** || **Description of this Area** || **General Consensus Statement** ||
 * Consent Directive Structure ||  || The general consensus agreed to is to use the HL7 CDA Consent Directive DSTU as a starting point for storing and transmitting consent directives.

This recommendation is intended to support both opt-in/opt-out (sometimes referred to as "simple" consent and more granular consent directives. ||
 * Query for Consent Directive Location ||  ||   ||
 * Consent Directive Location Response ||  ||   ||
 * Query for Consent Directive ||  ||   ||
 * Consent Directive Response ||  ||   ||
 * Testing Recommendations for CDA Header ||  || The general consensus agreed to at the S&I Framework F2F was to support testing of CDA document-level segmentation, through the use of the HL7 V3 ConfidentialityCode. ||
 * Segmentation (Annotation) Mechanism ||  ||   ||
 * Sending Segmented Patient Data ||  || The general consensus of the workgroup was to define a required level of metadata that would need to sent with patient data. ||
 * Implementation Guide Selection ||  ||   ||

Introduction
The structure of this Consensus Statement is as follows:
 * Description of the context
 * Summaries of workgroup analysis and decisions to date
 * Use of supporting visuals and guidance (where appropriate)

The consensus statements for review by the tiger teams are outlined in **BOLD. These statements will appear in the document and represent preliminary consensus, drawn from the activities of the tiger team to date.**

The S&I Framework Consensus Process can be reviewed here.

Use of Conformance Language in Implementation Guidance
It is the expressed intent that all conformance constraints are well defined in the implementation guidance for Data Segmentation and are populated into an appendix. Conformance statements and criteria should be derived wherever possible from the underlying profiles and standards under consideration.


 * Keywords to Indicate Requirement Levels**

An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) Note that the force of these words is modified by the requirement level of the document in which they are used.
 * MUST** or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
 * MUST NOT** or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
 * SHOULD** or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
 * SHOULD NOT** or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
 * MAY** or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item.

Issues and Challenges
The Data Segmentation initiative looked closely at the issues and challenges that were identified in the Data Segmentation Use Case.
 * Additional issues were identified that were specific to policy and technology, and were reviewed in the context of the S&I Framework Data Segmentation Use Case
 * Segmentation based on controlled vocabularies (defining how this specifically would work)
 * Use of Optional, Required, and Required if Known optionality for each of the datasets
 * The sheer number of standards and profiles to be reviewed creates a challenge for developing implementation guidance that can harmonize among different organizations

Consent Directive Structure

 * The initial recommendation from the Consent Management Tiger Team is to use the HL7 CDA Consent Directive DSTU (//official standard name will be added//). The implementation guidance that is developed will focus on using the CDA - Consent Directive as the mechanism for both opt-in/opt-out consent directive (simple) and granular consent (complex).**


 * Benefits**
 * Ensuring flexibility of implementation - use of HL7 ensures broad community support, and changes will be made much easier (comment and finalization process is clear)
 * Support for XACML (computable mechanism) to create rules for segmentation
 * Vendor familiarity with Consolidated CDA implementation


 * Issues**
 * Local and regional variations and what that might look like - //Link to examples of variations//
 * Industry adoption is low (this is due to DSTU status of the implementation guide)
 * Vocabularies are similar for clinical information - //show examples//

Query for Consent Directive Location
Implementers MAY use the following standards to query for a consent location:
 * Use IHE XUA to assert identity

Query for Consent Directive

 * Implementers should use an identity assertion mechanism to asset their identity to the receiver of the query. Implementers MAY use IHE XUA to assert identity**

Testing Recommendations for CDA Header

 * Potential Benefits**


 * Potential Issues**


 * Pilot Testing Strategy**

Segmentation (Annotation) Mechanism
Implementers MAY use the HL7 V3 ConfidentialityCode vocabulary within the  element in the CDA R2 Header to segment a CDA document.

The workgroup will continue to explore the possibility of using hData paragraph-level tagging to inform the strategy for CDA entry-level tagging of PHI.

Position on Segmentation of Medications

 * Potential Benefits**


 * Potential Issues**


 * Workgroup Recommendations**


 * Pilot Testing Strategy**

Position on Segmentation of Diagnoses

 * Potential Benefits**


 * Potential Issues**


 * Workgroup Recommendations**


 * Pilot Testing Strategy**

Position on Segmentation of Encounters

 * Potential Benefits**


 * Potential Issues**


 * Workgroup Recommendations**


 * Pilot Testing Strategy**

Position on Segmentation of Procedures

 * Potential Benefits**


 * Potential Issues**


 * Workgroup Recommendations**


 * Pilot Testing Strategy**

Consensus Roadmap

 * CDA Consent Directive Enhancements**


 * IHE XDS Enhancements**


 * Additional Roadmap Items**

There should be a common catalog of patient consent configurations that are made available as part of this implementation.

include component="page" wikiName="siframework" page="space.template.inc_contentleft_end"