August, 2018 CBCP Conference Call

Back to CBCP Main Page

August 7, 2018 CBCP Conference Call

Back to CBCP Main Page

Attendees

	Member Name		x	Member Name		x	Member Name		x	Member Name
x	Johnathan ColemanCBCP Co-Chair		x	Suzanne Gonzales-Webb CBCP Co-Chair		x	Jim Kretz CBCP Co-Chair		x	David Pyke CBCP Co-Chair
x	Kathleen Connor Security Co-Chair		x	Mike Davis		.	John Moehrke Security Co-Chair		x	Diana Proud-Madruga
x	Chris Shawn		.	Neelima Chennamaraja		.	Joe Lamy		.	Greg Linden
x	Irina Connelly		.	Saurav Chowdhury		x	Dave Silver		x	Francisco Jauregui
.	Mark Meadows		.	Amber Patel		x	Becky Angeles		.	Jennifer Brush
.	Mohammad Jafari		.	Ali Khan		x	Ken Salyards		.	Michael Gu
x	David Staggs		.	Bonnie Young		.	Ioana Singureanu		x	Beth Pumo
.	Lawless		.	Ken Lord		.	[mailto:]		x	[mailto:]

Back to CBCP Main Page

Agenda

1. Roll Call, Agenda Review
2. Meeting Minutes approval: (not ready)
   • July 31
   • July 26 - confirm
   • June 17
3. eLTSS Update - Irina / Becky
   • eLTSS gForge folder: https://gforge.hl7.org/gf/project/cbcc/docman/eLTSS%20-%20%20ONC%20Electronic%20Long-Term%20Services%20and%20Supports
4. Privacy - Is Privacy Obsolete update - Mike Davis
5. FHIR Consent
   • FHIR CPs for review
   • FHIR Consent CPs are located: link to ALL Consent Change requests
   • FHIR Consent / Consent contract
     • Continued discussion
     • Vote?
6. Baltimore WGM DRAFT posted (Suzanne working on)

Meeting Minutes DRAFT

Chair - Dave Pyke

No meeting minutes

eLTSS

• Final (corrected) PSS posted in gForge: https://gforge.hl7.org/gf/project/cbcc/docman/eLTSS%20-%20%20ONC%20Electronic%20Long-Term%20Services%20and%20Supports

• final touches are being added to white paper
• ONC will be reviewing - please send any additional comments to Irina LAST DAY
• PSS IS APPROVED! by TSC
  • once received information from CMS and ONC - Irina will submit items to publishing before the 19th with final version
• regarding formatting: adding line numbers ARE helpful (and preferred for commenters)

Privacy Obsolete

• no new information, no update

For remainder of conversation - Suzanne assumes Chair FHIR Consent Continued discussion from last week:

• Comments are FHIR resources cannot be linked are trued (Mike)
  • You can't get to a contract by going through a consent resource - cannot be linked in that way
  • you attach a link via a source for a consent.source (DPyke)
• Paul it’s not that you can’t point from one resource to another; resources must be linked together (that is not Restful)

DPyke - cannot go from contract to consent

Paul: proposal as written - that you ever have a contract... and further and you can only look up the contract via resource; in the event you have a resource, you must create a registry... and

• Architected like that is not Restful

DPyke - a registry of what...? Paul - DPyke has entered se; document would be linked as

Kathleen - inefficient and not restful ; if they have chosen to use the FHIR contract for that purpose.

Johnathan - you have heard some opposition to the language as written - have not heard modification to more language that is agreeable;

DP - we need to vote down the language; and then start the wordsmithing.

DPyke the current objection is that we are constraining the language.

Paul - we are not telling them how we can be building... we are limiting how...

Johnathan - not comfortable as written

ONC interoperability standard advisory 2019 includes BPPC application FHIR consent and FHIR contract as candidates for computable consent (Kathleen)

• Johnathan - suggest where consent resource is one of the best ways / or preferred ways (change from only way); we cannot specify information.

DPyke - only place aware of that are us are using contract is in US and MiHIN, both of which are Us- realm... kc - MiHIN , cener (DSTU 2) we have not done FHIR consent either, DPyke and no one says you have to change a DSTU2 implementation

Current proposed language in motion:
#1 consent resource is the correct (and best) way to store and exchange computable consent agreement in a FHIR environment
#2 formal consent documents are contracts and you may use the contract resource to capture that aspect of them for attachment to the consent resource as a source document
#3 while consent information may sometimes be found in document Reference, Binary, Contract and other resources, Consent is the principle resource for representing consent-related information and is the endpoint where systems should expect to find this information 

MOTION ; Accept the language of the motion as stated (David/Paul)

• Becky: abstain
• MikeD: obj
• Paul: obj
• Johnathan: obj
• Francisco: obj
• DPyke: affirmative
• DStaggs: obj
• Diana: obj
• Kathleen: obj
• Jim: obj
• Beth: ? no response
• Irina: ? no response
• Suzanne: chair/no vote

Vote: Abstentions: 1; Objections: 9; Affirmative: 1 motion: does not pass / fails

Johnathan: Paul Lithuania example

New topic for discussion: Mike: IG are the best way to present that type of information Paul cannot force business process to be technologically...

• Not sure why we are doing this at all... not opposed to guidance; i.e. it’s like saying java is the preferred software to write language...

Jim: would you endorse first bull if remove: 'to store' DPyke : updated 'to exchange'

Kathleen - would like to put out that the entire statement should be removed; and... in contract... leave contract as is. Some feel claim starts as an invoice... would like to go back, do not recraft and take the governance issue in trying to set another... we are not representing the discussion is between FM CPCP for one WG depends on what we do... (40:52) Paul - find to think that the consent resource is a well signed resource to implement (from someone) for a registry/exchange of a registry. that's behind the front door. but its cant be used for a repository because it doesn't have the full content

Let's strike this. level situation as normal as it has been... then we don’t' need to make a statement, we don’t' need to state a preference, and not move forward... ey gus do what you want to do. Kathleen; there are two artifacts in FHIR recognized by ONC and Canada certain source can talk about cases; because governance issue down the road are further reaher, we can come up with word here but is through practitioner resource;

Kathleen - the name of the resource is consent; the contract is consent directive and that is what seems to be munged in this conversation;

• use case is computable consent

Johnathan - informative white paper - comparative capabilities; so, implementers can make an informative decision moving forward; people are jumping from one to other - without considering the other

• Mike agrees 0 would satisfy the intent of the three bullets

Striking language and move forward in another direction. Mike: Who is going to write? - Kathleen - if Johnathan will be project lead, Kathleen will write part for one section; someone else will need to write another section Johnathan - wants it to be used and add guidance where we can post Kathleen - if WGs agree it can be placed in the FHIR ballot as part of guidance

Moving this to a white paper to be balloted in FHIR (potentially) PSS and other administrivia will be started once start of paper has been initialized

Dave will forward language to presenter of language results of the vote and additional details

Motion to adjourn: (Suzanne) meeting ended 9:50 Arizona time--Suzannegw (talk) 12:51, 7 August 2018 (EDT)