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

September 08, 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
x Diana Proud-Madruga x Rick Grow x Harry Rhodes
Serafina Versaggi Ioana Singureanu David Bergman
x Steve Eichner . Steve Daviss . Wende Baker
. Reed Gelzer . Marlowe Greenberg x 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 September 01, 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. gforge link http://gforge.hl7.org/gf/download/docmanfileversion/8888/13458/FHIR%20AuditEvent%20May-Sept.xlsx
  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)

Approve Meeting Minutes from September 01, 2015 CBCC Conference Call

The minutes from the September 1 meeting were unanimously approved.


FHIR Consent Directive ballot resolutions

FHIR Consent Directive CP 6285

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

While I’ve marked this comment for deferral with ballot resolution = consider for future use, John may find this example adequate and withdraw his comment. Better yet, he’d consider helping me 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 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.

CBCC motion (Johnathan/Mike) to ACCEPT the above candidate consent directive use cases (expect those involving break-glass):

Motion PASSES - Move forward with use cases 1, 3, and 6 above. (10 Approve; 0 Object; 1 Abstain - Harry Rhodes)

Block vote to approve the following CP resolutions - (10 Approve; 0 Object; 1 Abstain - Harry Rhodes)

FHIR Consent Directive CP 6861

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

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

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.

Data Provenance IG update

We viewed recent changes that were made to the Data Provenance IG. These changes include a more extensive overview that provides more information so that folks feel more comfortable about the origination of the project and provides information on how it relates to the S&I Framework Data Provenance initiative. The DProv IG builds on the DS4P IG, which brought in C-CDA templates and added security. Contributors are aligning the DProv IG with Meaningful Use-required C-CDA templates.

Joint EHR, Security, Privacy Vocabulary Alignment

Project participants refined the process to define terms based on guidance from ISO. They are searching for the best possible existing definitions and, to make them EHR specific, they are specifying properties for the terms. Diana called for volunteers to search for definitions and send them to her so that she can turn them in to Gary Dickinson for inclusion in the ISO 21089 standard, "Trusted End to End Information Flows." The deadline for submitting definitions to Diana is Monday, September 14.

Meeting adjourned at 1153 PDT