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

September 01, 2015 CBCC Conference Call

From HL7Wiki
Jump to navigation Jump to search

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 Mike Davis Security Co-Chair Max Walker CBCC Co-Chair
x Suzanne Gonzales-Webb CBCC Co-Chair John Moehrke Security Co-Chair x Jim Kretz CBCC Co-Chair
x Kathleen Connor Ken Salyards CBCC Interim Co-Chair Lori Simon CBCC Interim Co-Chair
Diana Proud-Madruga x Rick Grow Harry Rhodes
Serafina Versaggi x Ioana Singureanu David Bergman
x 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 Sandra Huyck
. William Kinsley Debbie Bucci Chirag Bhatt
. Linda Bailey-Woods Lee Wise Lori McNeil Tolley
. Peter Fiaspa, Colombia University [mailto: Rob Horn ] [mailto: ]


Back to CBCC Main Page

Agenda

  1. (05 min) Roll Call, Approve Meeting Minutes from August 25, 2015 CBCC Conference Call
  2. FHIR Consent Directive ballot resolutions - Kathleen
    1. vote to approve deferral of CPs
    2. review possible resolutions if time (for group approval)
  3. (05 min) Patient Friendly Language for Consumer User Interfaces - (Standing Agenda Item) - Update
  4. (05 min) Data Provenance IG Update (Standing Agenda item)
  5. Behavioral Health Domain Analysis Model (HL7 BH DAM) Update update
  6. (10 min) TSC Review on Outstanding work for: HL7 Version 3 Domain Analysis Model: Behavioral Health Record, Release 2 (PI ID: 1174) (1st Informative Ballot) - 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)
  7. (10 min) PASS Access Control Services Conceptual Model - (Standing agenda item) update (Diana)
  8. (10 min) Joint EHR, Security, Privacy Vocabulary Alignment - (Standing agenda item) update (Diana/Mike)
  9. (10 min) Action Item Review (if any)

Meeting Minutes (DRAFT)

Meeting Minutes for August 25 approval Meeting Minutes for August 25 0 abstention, 0 objections, approved: 8

FHIR Consent Directive MOTION:Vote to affirm the Deferral of the the following five CP Take up the CPs we need to address on next weeks call, and come up with dispositions we can agree. (Kathleen/Rick) Further discussion: Abstentions: none, Objections: none, Motions Passes: 8

RE: FHIR Tracker List of outstanding CBCC CPs, which was sent to WGs on Friday, must be deferred or resolved before Monday so that the FHIR DSTU ballot can move forward. [See CBCC Tracker Listings below.]

Following guidance from Paul Knapp and Lloyd, Kathleen completed the preliminary work that CBCC needs to review and vote to defer all four CPs no later than Tuesday 9/1.

Specifically, Kathleen marked all with status = Deferred and Ballot Resolution = Not related [for negative comments] or Consider for Future Use [for affirmative comments].

Resolution comment: The resolution for this CP is "deferred" because the Consent profile is not being included in DSTU 2. As soon as DSTU 2 is published, all "deferred" change requests will be changed back to Triaged again.

In addition, Kathleen included potential ballot resolution dispositions, which we can also vote on Tuesday or delay a bit, but not for long.

CBCC

  • Critical (Negative vote) - Need work group vote (and possible application) by Aug 31, 4 Eastern (IGs may have until Sept 7th) (1)
  • Priority (Substantive) - Should determine if substantive (and prioritize applying change if they are) by Aug 31, 4 Eastern (IGs may have until Sept 7th) (4)


The Tracker List keeps changing, probably due to changes I’m making, and by Saturday PM it looked like this:

CBCC (2)

Impacted Resources: None

Priority (Substantive) - Should determine if substantive (and prioritize applying change if they are) by Aug 31, 4PM Eastern (IGs may have until Sept 7th) (1)

Priority (Negative vote) - Vote is not captured or recorded in invalid format - Must be fixed by EOD Sept 14 (1PM ET)


Below are specifics for each of the CPs:

FHIR Consent Directive CP 6137

Comment is a negative major from Lloyd, for lack of Consent Directive examples i.e., XML/JSON instances that are rendered.

Proposed Resolution: The resolution for this CP is "deferred" because the Consent profile is not being included in DSTU 2. As soon as DSTU 2 is published, all "deferred" change requests will be changed back to Triaged again.

Persuasive, but non-substantive. Propose reuse of the Contract example:

A human-readable rendering of the consent directive.

<ConsentDirective xmlns="http://hl7.org/fhir">
  <id value="C-123"/>
  <text>
    <status value="generated"/>
</ ConsentDirective>

{

  "resourceType": "Contract",
  "id": "C-123",
  "text": {
    "status": "generated",

"div": "

!-- Snipped for Brevity -->

"

  }
}

FHIR Consent Directive CP 6285

Comment from John Moehrke’s CP, which was not assigned a ballot weight (e.g., affirmative or negative)

Kathleen has marked this comment for deferral with ballot resolution = consider for future use, confirm with John that this example adequate and if so, withdraw his comment. (Better yet, consider helping Kathleen write the XML/JSON so we can add one or more of his BPPC examples to the profile.)

John’s Comment:

Might I suggest that the ConsentDirective project include a "Basic-ConsentDirective" that supports blanket consents without exceptions. Essentially the common HIE policies from BPPC. These would be scoped to sharing beyond the original organization and purpose for which the health information was created. This form of a Consent Directive would need only (identifier, issued, applies, subject, authority, domain, type=consent, subtype=<some vocabulary>, and possibly friendly and legal). This Basic Consent Directive would support the following HIE subtypes:

  1. Opt-In -- Agree to publish "All" healthcare information. Agree to Use and Disclosure to "any" authorized individual of a "Treatment" or "Payment" organization "For the Purpose" of "Treatment" or "Payment". No Redisclosure allowed without further authorization. This agreement does not authorize other accesses.
  2. Opt-Out allowing break-glass -- Agree to publish "All" healthcare information. Agree to Use and Disclosure to "any" authorized individual of a Treatment organization for specifically "Emergency Treatment" PurposeOfUse, and Payment of those treatment. This agreement does not authorize other accesses.
  3. Opt-In summary access only -- Agree to publish "All" healthcare information. Agree to Use and Disclosure to "any" authorized individual of a "Treatment" or "Payment" organization "For the Purpose" of "Treatment" or "Payment"; to only the medications and allergies summary. No Redisclosure allowed without further authorization. This agreement does not authorize other accesses.
  4. Opt-In break-glass summary access only -- Agree to publish "All" healthcare information. Agree to Use and Disclosure to "any" authorized individual of a "Treatment" organization "For the Purpose" of "Emergency Treatment" and Payment of those treatment; to only the medications and allergies summary. No Redisclosure allowed without further authorization. This agreement does not authorize other accesses.
  5. Opt-Out no break-glass -- Agree to publish "All" healthcare information. This agreement does not authorize any accesses.
  6. Opt-Out completely -- Agree to publish "No" healthcare information beyond originating organization intended use.

Proposed Resolution:

Throughout CBCC development of the FHIR CD profile, BPPC was considered a foundational use case, so support was built in from the first.. Attached and at the FHIR BPPC Consent Directive.xlsx Simple FHIR BPPC Consent Directive.xlsx gforge link is an example spreadsheet to illustrate how the Simple BPPC Consent Directives described in his comments could be satisfied.

FHIR Consent Directive CP 6861

Jim Kretz Comment:

Is "subject" supposed to identify the data covered by the consent? Could we use SearchParameters perhaps an improvement? This would allow us to describe the criteria for matching resources.

Proposed Resolution: The resolution for this CP is "deferred" because the Consent profile is not being included in DSTU 2. As soon as DSTU 2 is published, all "deferred" change requests will be changed back to Triaged again.

Wrt to suggestion to use SearchParameters: Not sure that this is applicable here. Also not sure that the following is entirely correct, but this is how I think it works. The ConsentDirective.subject is defined as Patient information and actions taken on that information that are governed by this Consent Directive. It specializes the Contract.subject definition: "Who and/or what this Contract is about: typically a Patient, Organization, or valued items such as goods and services."

Examples are Patient Resource/HIE BPPC Consent Directive Policy Resource/Patient Health and Administrative Resources and Resource Types. If Patient health related Resources are listed, then those contain URIs for their location. If Patient health related ResourceTypes are listed, then use the Search Parameters provided with Contract Resource for subject.

FHIR Consent Directive CP 6864

Jim Kretz Comment:

Only 1 element is "mandatory": "mandatory" 1..1 is the "binding" choice.http://hl7.org/fhir/2015May/consentdirective-consentdirective-definitions.html#consentdirective-consentdirective.ConsentDirective.binding[x] . Other elements appear in optional parent elements and thus they are mandatory only if the parent is mandatory.

Proposed Resolution: The resolution for this CP is "deferred" because the Consent profile is not being included in DSTU 2. As soon as DSTU 2 is published, all "deferred" change requests will be changed back to Triaged again.

However, guidance provided by FHIR Infrastructure Group, which triaged this CP to CBCC should adequately address the concern: Child elements aren't mandatory even if parent is 1..1. All that's required is that some descendant has a value.

FHIR Consent Directive CP 6865

Jim Kretz Comment:

It would be useful to create Bundles that specifies a request and a consent in a single transaction (i.e. SSA use case) to give us a sense of real-life applications of this profile.

Proposed Resolution:

The resolution for this CP is "deferred" because the Consent profile is not being included in DSTU 2. As soon as DSTU 2 is published, all "deferred" change requests will be changed back to Triaged again. Suggestion needs a volunteer to explain the use case and create the Bundle. However, it is not a requirement for this profile. Not sure whether it would be considered an extension. Need to consult with CBCC FHIR Facilitator.


Patient Friendly Language - Update

  • awaiting confirmation of publication

Data Provenance IG

  • the documentation continues to be finalized
  • still waiting for Sean Muir to fix the constraint/context tables to work more smoothly
  • may be able to discuss next week (15-20 minutes)

BH DAM - Update

  • the ballot document is out for review and comment (though any comments submitted now will not be part of the ballot reconciliation process)

PASS Access Control Services Conceptual Model

  • submitted for September ballot
  • ready for comments

Joint EHR, Security, Privacy Vocabulary Alignment

  • request made for shortening the process
    • sticking more to the definitions as they currently exist from reliable sources
    • keeping the tone of the definitions high level but still providing meaningful definitions, and adding to the extended definitions only if clarification is needed
    • applying the technique that the group has adopted from W3C to elaborate on the definitions and show variations

Motion to adjourn: (Jim) --Suzannegw (talk) 15:00, 1 September 2015 (EDT)