This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "October 27, 2015 CBCC Conference Call"

From HL7Wiki
Jump to navigation Jump to search
Line 109: Line 109:
  
  
 
+
Clarify reballoting
 +
add R1, $2
 +
MOTION: (Kathleen/Glen) send (document name: ) with the two changes to PAC to go forward to the executive
 +
committee 
 +
Objections: none, Abstentions: 1 (Johnathan), Motion Passes (10)
  
  
Line 121: Line 125:
  
 
[http://www.hl7.org/events/harmonization/ http://www.hl7.org/events/harmonization/]
 
[http://www.hl7.org/events/harmonization/ 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'' '''
 
VALUE SET: '' '''ActConsentDirectiveType'' '''
Line 256: Line 233:
  
 
Example: Where there is a need to inform the subject of potential health issues.
 
Example: Where there is a need to inform the subject of potential health issues.
 +
 +
MOTION: (kahtleen/Johnathan) accept and approve for submission to final harmonization
 +
Disccusion: John M are these described w enough detail, where an organization can create an RBAC rules? the OPTOUT is complete, we have had problems with the concepts, with need to describe what limits authorized users meant.  (comment) not saying we shouldn't go forewad, but we may need to further refine
 +
* these are the code on the consent directive, a high level characterization as to what kind of consent they are looking at vs the type of the procedure. there is further elaboration regarding service (BPPC?) where you can be very specific, i.e. further information of the author, etc.
 +
* just channeling the concern when people have attempted to use--at a high level its fine, but between organizations the argument needs to be determined
 +
* this points to the consent directive, not the CD itself
 +
* as long as we are understanding that we need to eventually
 +
 +
Objections: none; Abstentions: none; Motion passes: 11 passes
 +
 +
'''FHIR Consent Profile Timeslot'''
 +
* Doodle Poll sent out by John
 +
two slots (most choices....that also have Kathleen and Johnathan
 +
** Tuesday at 4:00 Central time
 +
** Wednesday at 5:00 Central time (6ET) -
 +
MOTION: (JohnM/Ioana) Proposal Wednesday at 5:00 Central time (6ET)
 +
Abstentions: none; Objections: none; Motion Passes: 11
 +
Meetings will start at this time slot TOMORROW Wednesday 10/28
 +
CBCC Chair required (Johnathan/Suzanne as CBCC co-chair will be available to chair); we will use JOhnathan's GoToMeeting...

Revision as of 18:49, 27 October 2015

Community-Based Collaborative Care Working Group Meeting

Back to CBCC Main Page

Meeting Information

Attendees

Member Name x Member Name x Member Name
x Johnathan ColemanCBCC Co-Chair x Suzanne Gonzales-Webb CBCC Co-Chair Jim Kretz CBCC Co-Chair
. Max Walker CBCC Co-Chair x Mike Davis Security Co-Chair x 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 x 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
x Neelima Chennamaraja Susan Litton x [mailto: Glen Marshall]
. William Kinsley . Debbie Bucci Chirag Bhatt
. Linda Bailey-Woods x Lee Wise Lori McNeil Tolley
. Peter Fiaspa, Columbia University Gary Dickinson x Russell McDonell


Back to CBCC Main Page

Agenda

  1. (05 min) Roll Call, Approve Meeting Minutes from October 20, 2015 CBCC Conference Call
  2. Consent Directive Recirculation to NIB VOTE
  3. Comments on ONC Draft Interoperability Standards Advisory- Kathleen
    • e-mail sent to listserve (see also attached: 2016-Interoperability)
  4. (05 min) Patient Friendly Language for Consumer User Interfaces - (Standing Agenda Item) - Update
  5. (05 min) HL7_CDAR2_DPROV_IG_DSTU10-22-2015.pdf - (Standing Agenda Item) - Update
  6. Draft CBCC and Security WG harmonization proposals for review
  7. (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)
  8. FHIR Meeting Timeslot
  9. (10 min) PASS Access Control Services Conceptual Model - (Standing agenda item) update (Diana)
  10. (10 min) Joint EHR, Security, Privacy Vocabulary Alignment - (Standing agenda item) update (Diana/Mike)


Meeting Minutes (DRAFT)

'Consent Directive Recirculation to NIB

  • submit previous NIB (no change in scope)
  • update as needed as going through approval processes (ballot announcement)
  • refresh interested parties (add patient choice project in ONC as interested party)

MOTION: submit previous NIB, with update to add ONC patient choice project as an interested party, plus the reason why we are reballoting as per Lynne's e-mail 'unable to complete recirculation in time (Johnathan/Ioana) Objections: none, Abstentions: none Motion Passes (11) Lynn will need to submit NIB on the HL7 side, Ioana will assist facilitation of NIB


Clarify reballoting add R1, $2 MOTION: (Kathleen/Glen) send (document name: ) with the two changes to PAC to go forward to the executive committee Objections: none, Abstentions: 1 (Johnathan), Motion Passes (10)


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/

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.

MOTION: (kahtleen/Johnathan) accept and approve for submission to final harmonization Disccusion: John M are these described w enough detail, where an organization can create an RBAC rules? the OPTOUT is complete, we have had problems with the concepts, with need to describe what limits authorized users meant. (comment) not saying we shouldn't go forewad, but we may need to further refine

  • these are the code on the consent directive, a high level characterization as to what kind of consent they are looking at vs the type of the procedure. there is further elaboration regarding service (BPPC?) where you can be very specific, i.e. further information of the author, etc.
  • just channeling the concern when people have attempted to use--at a high level its fine, but between organizations the argument needs to be determined
  • this points to the consent directive, not the CD itself
  • as long as we are understanding that we need to eventually

Objections: none; Abstentions: none; Motion passes: 11 passes

FHIR Consent Profile Timeslot

  • Doodle Poll sent out by John

two slots (most choices....that also have Kathleen and Johnathan

    • Tuesday at 4:00 Central time
    • Wednesday at 5:00 Central time (6ET) -

MOTION: (JohnM/Ioana) Proposal Wednesday at 5:00 Central time (6ET) Abstentions: none; Objections: none; Motion Passes: 11 Meetings will start at this time slot TOMORROW Wednesday 10/28 CBCC Chair required (Johnathan/Suzanne as CBCC co-chair will be available to chair); we will use JOhnathan's GoToMeeting...