May 31, 2016 CBCC Conference Call

Community-Based Collaborative Care Working Group Meeting

Back to CBCC Main Page

Attendees

	Member Name		x	Member Name		x	Member Name
x	Johnathan ColemanCBCC Co-Chair		x	Suzanne Gonzales-Webb CBCC Co-Chair		x	Jim Kretz CBCC Co-Chair
.	Max Walker		x	Mike Davis		x	[mailto: John Moehrke] Security Co-Chair
x	Kathleen Connor Security Co-Chair		x	Ken Salyards			Lori Simon
x	Diana Proud-Madruga SOA Co-Chair		x	Rick Grow		.	Harry Rhodes
.	Serafina Versaggi		x	Ioana Singureanu		x	Glen Marshall
.	Steve Eichner		x	Neelima Chennamaraja		.	Mike Lardiere
x	Beth Pumo			M'Lynda Owens		x	Lee Wise
x	Paul Knapp		.	Matt Peeling			Brian Newton
x	Oliver Lawless			Lisa Nelson		.	Amanda Nash
	Russell McDonell			Susan Litton			David Bergman
.	Linda Bailey-Woods			Debbie Bucci		x	Paul Knapp
	Keith Boone			Lori McNeil Tolley		x	Duane DeCouteau
x	Mohammed Jafari			Rob Horn			Gary Dickinson
	William Kinsley		x	David Pyke		x	Ken Sinn

Back to CBCC Main Page

Agenda

1. (05 min) Roll Call, Approve Meeting Minutes from May 24, 2016 CBCC Conference Call
2. (15 min) CDA R2 Implementation Guide: Privacy Consent Directives R1 (PID 553) Publication update
3. (10 min) Behavioral Health Data Exchange CrossParadigm IG: Project 800) update - Ioana (no update)
4. (15 min) Consent Tracker Resource - request for approval to commit to build
5. (05 min) Standards Privacy Impact Assessment (SPIA) Cookbook Update - Rick, not given
6. (05 min) Pass Audit Service Conceptual Model, not given
7. (05 min) PASS Access Control Services Conceptual Model - (Standing agenda item) update (Diana), not given
8. ( min) CBCC FHIR Consent Directive (combined with consent tracker discussion)
9. next week - WGM Meeting Minutes

Meeting Minutes (DRAFT)

Meeting chaired by Suzanne

Roll Call, Approve Agenda, Approve Meeting Minutes from May 24, 2016 CBCC Conference Call

• Abstentions: none; Objections: none; Approved: 22

CDA R2 Implementation Guide: Privacy Consent Directives R1 (PID 553) Publication update

• in process (Neelima)

Behavioral Health Data Exchange CrossParadigm IG: Project 800)

• in process

___

Consent Tracker Resource - request for approval to commit to build (see briefing below)

Consent Tracker Resource Description Scope and Usage

• Important decisions that patients and their personal representative make about activities or information, which concern their health and well-being, are typically captured as contractually binding permissions, obligations, and prohibitions known as Consent Directives. Consent Directives memorialize these decisions as rules specifying rights that the patient, as grantor, conveys to a grantee, such as a provider, a health app, a health plan, HIE, or clinical trial.

• When patients and providers create and manage privacy and medical Consent Directives, including clinical trial, research, and advanced directives, three components are typically required:

1. Paper or electronic forms in which a patient documents permissions granted or restriction limiting activities related to e.g.: patient care [aka medical consent directive], participation in clinical trials [aka research consent directive], or collection, access, use, and disclosure of information [aka privacy consent directive]
2. The legally binding recording of a Consent Directive contract for which both the patient grantor and the data controller or processor grantee are held accountable once executed. A legally binding Consent Directive may transition a series of lifecycle stages or 'status', which may indicate e.g., whether the Consent Directive form has been signed by the patient and accepted by the grantee, whether the patient has revoked or renewed it.
3. A means for managing or "tracking" Consent Directives at all stages in their lifecycle, from the patient, institutional, or jurisdictional policy, to an offered Consent Directive form, and on to the executed Consent Directive, which may be pended, disputed, revoked, terminated, or renewed.

• The FHIR Consent Tracker Resource supports the third requirement by providing a flexible means for tracking and conveying intra-and inter-enterprise the lifecycle, provenance, privacy, and security metadata used for Consent Directive management workflows, such as obtaining patient authorizations and restrictions, and Consent Directive enforcement using security labeling and privacy protective services to comply with access control decisions.
• The Consent Tracker Resource is agnostic to the media used to capture the Consent Directive. I.e., it can track the location from which an authorized user may retrieve a copy of or verification of the existence of a legally binding Consent Directive regardless of whether it is captured as a paper, scanned or otherwise unstructured representation; IHE Basic and Advanced Patient Privacy Consents; HL7 CDA Consent Directives, a FHIR Consent Directives, or the patient friendly FHIR Consent Directive form and completed instance, i.e., a FHIR Consent Directive Questionnaire and Questionnaire Response.

Consent Tracker Resource Proposal (see description above) Discussion

• interoperable codes will be used (are in use) for type of consent
• Mohammed is prepared to place in the build pending approval, otherwise Paul Knapp (who started the work) is able to place in FHIR if necessary; will work on the Consent directive FHIR profile in order for review

How is this different from the current consent resource mechanism to manage the consent? (JMoehrke)

Motion: approving a resource proposal for a consent tracker under the current PSS, and placing in the build as pre-applied(Kathleen/Mike)

Discussion: Acknowledgement of Oliver discussion points

• John comment: questions posed before still need to be answered before the resource proposal can be persuasive to FMG. In that how is this fundamentally different enough to call for a new resource type? From document reference where it is derived from? From FHIR consent? And very specifically (everything just presented) is already in the FHIR consent, and everything else is optional, there is nothing that presents someone from using the FHIR consent resource or FHIR consent profile in the way it’s described.
  • the discussion on Friday - significant input received that the consent resource would be too cumbersome, and as a result the consent resource would be much more than needed than just a basic tracker, which led to the consent tracker resource.

Friendly amendment –

Result of this motion is that you need to use the FHIR Wiki site and fill out a resource proposal; you need to be clear why this resource is needed/why it isn’t the same as the current FHIR consent

VOTE: Abstentions: 3 abstain (KenS, Lee, Beth); Objections: 3 Oliver/JohnM (with note: "a compelling use case has not been presented here to move forward")/and one other; 16 affirmatives (correction from 17 as stated during meeting)

Add link: add FHIR resource proposal (sent by John M)

John Moehrke FHIR approach. If we were to switch from an IG to a resource? FMG approached — there is an interest in seeing a resource proposal, but it also fits under the same PSS

• Two levels – yes, this fits under our project scope statement; when originally proposed as a resource, we switched to an IG
• The original paperwork for our consent IG was written for a resource. (we went from resource to profile, then the idea of an IG came in)

In the same way that Kathleen's resource fits under the PSS, this also fits under the PSS;

MOTION: Go forward with the consent resource (JohnM / Ken Salyards)

• Note: This is disconnected from profile and contract (wholly owned by CBCC); the scope of the resource is narrower than the IG we have; does not affect any item that is currently in the build
• VOTE: Objections: 2 Paul (w note/ ’’current motion does not cover consent space’’) and one other; Abstentions: none; Approved: 20

and abandon the consent IG is a separate item

Meeting adjourned at 12:10 PDT --Suzannegw (talk) 17:34, 31 May 2016 (EDT)sgw