October 27, 2015 CBCC Conference Call

Community-Based Collaborative Care Working Group Meeting

Back to CBCC Main Page

Attendees

	Member Name		x	Member Name		x	Member Name
	Johnathan ColemanCBCC Co-Chair		x	Suzanne Gonzales-Webb CBCC Co-Chair			Jim Kretz CBCC Co-Chair
.	Max Walker CBCC Co-Chair			Mike Davis Security Co-Chair			John Moehrke Security Co-Chair
x	Kathleen Connor		.	Ken Salyards CBCC Interim Co-Chair			Lori Simon CBCC Interim Co-Chair
x	Diana Proud-Madruga		x	Rick Grow			Harry Rhodes
	Serafina Versaggi			Ioana Singureanu			David Bergman
	Steve Eichner		.	Steve Daviss		.	Wende Baker
.	Reed Gelzer		.	Marlowe Greenberg			Chris Clark, WV
.	Paul Knapp		.	Matt Peeling			Brian Newton
	Lisa Nelson		.	Mike Lardiere		.	Amanda Nash
.	Mohammed Jafari			Oliver Lawless			Keith Boone
	Neelima Chennamaraja			Susan Litton			Sandra Huyck
.	William Kinsley		.	Debbie Bucci			Chirag Bhatt
.	Linda Bailey-Woods			Lee Wise			Lori McNeil Tolley
.	Peter Fiaspa, Columbia University			Gary Dickinson			Russell McDonell

Back to CBCC Main Page

Agenda

1. (05 min) Roll Call, Approve Meeting Minutes from October 20, 2015 CBCC Conference Call
2. (05 min) Patient Friendly Language for Consumer User Interfaces - (Standing Agenda Item) - Update
3. (05 min) HL7_CDAR2_DPROV_IG_DSTU10-22-2015.pdf
4. (05 min) Behavioral Health Domain Analysis Model (HL7 BH DAM) Update
   • Unique Ballot ID: V3_DAM_BH_R2_I1_2015SEP, HL7 Version 3 Domain Analysis Model: Behavioral Health Record, Release 2 (Project Insight ID: 1174)
5. (10 min) PASS Access Control Services Conceptual Model - (Standing agenda item) update (Diana)
6. (10 min) Joint EHR, Security, Privacy Vocabulary Alignment - (Standing agenda item) update (Diana/Mike)
7. Comments on ONC Draft Interoperability Standards Advisory- Kathleen
   • e-mail sent to listserve (see also attached: 2016-Interoperability)

Meeting Minutes (DRAFT)

Draft CBCC and Security WG harmonization proposals for review on Tuesday’s CBCC and Security WG calls.

Submitted proposals are attached along with the Summary shown below. (Kathleen will give walk through)

Technical review of these initial proposals and input from the workgroups will be used to create the final proposals, which are due 11/08.

Draft Nov 2015 Harmonization proposals.docx – Summary for posting to Oct 27 CBCC and Security wiki agenda]

http://www.hl7.org/events/harmonization/

ActPrivacyLaw Technical Corrections

This is a Security Harmonization Proposal to make technical corrections on how this vocabulary was implemented

Proposal Summary: Rename ActPrivacyLawPrivacyPolicyType concept domain. Update binding to v:ActPrivacyLaw. Replace current ActPrivacyLaw definition, which is the definition of ActInformationSensitivity, with the correct one.

ActInformationAccessContextCode

This is a Security Harmonization Proposal to improve the definition of terms used to describe the policy context in which health information is collected/accessed/used/disclosed.

Proposal Summary: ActInformationAccessContext code definition revision and creation of value set.

ActConsentDirectiveType Value Set

This is a CBCC Harmonization Proposal to enable the DPROV IG to list multiple types of consent rules that apply to a CDA.

Currently, HL7 vocabulary has separate value sets for Consent Directive types with slightly different types of Consent rules.

As a workaround, the DPROV IG created an IG specific value set to combine both of the value sets listed below, but it would be better to have an HL7 approved value set.

Proposal Summary: Create the ActConsentDirectiveType Value Set as a union of the existing ActConsentType and ActConsentDirective ActCodes. Create parallel binding to the existing ActConsentDirectiveType Concept Domain, which is currently only bound to the ActConsentDirective value set.

VALUE SET: ActConsentDirectiveType

Description:

ActConsentDirective and ActConsentType codes are used to specify the type of Consent Directive or Consent Type to which, for example, a Consent Act conforms, to which a Security Observation (Security Label) refers to, or to which a Privacy or Security Act refers. V:ActConsentDirectiveType is the union of v:ActConsentDirective [2.16.840.1.113883.1.11.20425] and v:ActConsentType [2.16.840.1.113883.1.11.19897].

Supported Code Systems: ActCode (2.16.840.1.113883.5.4)

Contains 2 children of type unionWithContent

Bound to Domains:

ActConsentDirectiveType and ActConsentType (CWE) in R1 (Representative Realm)

The combined ActConsentDirectiveType Value Set value set would include the following codes:

ABSTRACT CONCEPT: _ActConsentDirective [abstract term] Description: Definition: Specifies the type of consent directive indicated by an ActClassPolicy e.g., a 3rd party authorization to disclose or consent for a substitute decision maker (SDM) or a notice of privacy policy.

Usage Note: ActConsentDirective codes are used to specify the type of Consent Directive to which a Consent Directive Act conforms.

LEAF CONCEPT: EMRGONLY (emergency only) Description: This general consent directive specifically limits disclosure of health information for purpose of emergency treatment. Additional parameters may further limit the disclosure to specific users, roles, duration, types of information, and impose uses obligations.

Definition: Opt-in to disclosure of health information for emergency only consent directive.

LEAF CONCEPT: NOPP (notice of privacy practices) Description: Acknowledgement of custodian notice of privacy practices. Usage Notes: This type of consent directive acknowledges a custodian's notice of privacy practices including its permitted collection, access, use and disclosure of health information to users and for purposes of use specified.

LEAF CONCEPT: OPTIN (opt-in) Description: This general consent directive permits disclosure of health information. Additional parameter may limit authorized users, purpose of use, user obligations, duration, or information types permitted to be disclosed, and impose uses obligations.

Definition: Opt-in to disclosure of health information consent directive.

LEAF CONCEPT: OPTOUT (op-out) Description: This general consent directive prohibits disclosure of health information. Additional parameters may permit access to some information types by certain users, roles, purposes of use, durations and impose user obligations.

Definition: Opt-out of disclosure of health information consent directive.

ABSTRACT CONCEPT: _ActConsentType [abstract term] Description:

Definition: The type of consent directive, e.g., to consent or dissent to collect, access, or use in specific ways within an EHRS or for health information exchange; or to disclose health information for purposes such as research.

LEAF CONCEPT: ICOL (information collection) Description:

Definition: Consent to have healthcare information collected in an electronic health record. This entails that the information may be used in analysis, modified, updated.

LEAF CONCEPT: IDSCL (information disclosure) Description:

Definition: Consent to have collected healthcare information disclosed.

SPECIALIZABLE CONCEPT: INFA (information access) Description:

Definition: Consent to access healthcare information.

LEAF CONCEPT: INFAO (access only) Description:

Definition: Consent to access or "read" only, which entails that the information is not to be copied, screen printed, saved, emailed, stored, re-disclosed or altered in any way. This level ensures that data which is masked or to which access is restricted will not be.

Example: Opened and then emailed or screen printed for use outside of the consent directive purpose.

LEAF CONCEPT: 'IRDSCL (information redisclosure) Description:

Definition: Information re-disclosed without the patient's consent.

SPECIALIZABLE CONCEPT: RESEARCH (research information access) Description: Definition: Consent to have healthcare information in an electronic health record accessed for research purposes.

LEAF CONCEPT: RSDID (de-identified information access) Description:

Definition: Consent to have de-identified healthcare information in an electronic health record that is accessed for research purposes, but without consent to re-identify the information under any circumstance.

LEAF CONCEPT: RSREID (re-identifiable information access) Description:

Definition: Consent to have de-identified healthcare information in an electronic health record that is accessed for research purposes re-identified under specific circumstances outlined in the consent.

Example: Where there is a need to inform the subject of potential health issues.