FHIR Consent June 03, 2016

HL7 CBCC FHIR Consent Working Meeting

Back to FHIR Consent Directive Project Main Page

Attendees

	Member Name			Member Name			Member Name
x	Johnathan ColemanCBCC Co-Chair		x	Kathleen Connor FM Co-Chair		x	John MoehrkeSecurity Co-Chair
x	Alexander Mense Security Co-Chair		.	Jim Kretz		x	Tarik Idris
x	Suzanne Gonzales-Webb CBCC Co-Chair		.	Diana Proud-Madruga		.	Pat Pyette
.	M'Lynda Owens		x	David Staggs		x	Glen Marshall
	Rob Horn		x	Beth Pumo			William Kinsley
.	Serafina Versaggi		.	Russell McDonell		x	Ken Sinn (Canada)
x	Igor Sirkovich		.	Mike Davis		x	Mohammad Jafari (VA/ESC)
	Ken Salyards			Adrian Gropper		.	[mailto: Andrew Rampolla (SSA)]
x	[mailto: Wayne Kubick		x	[mailto: David Pyke		x	[mailto: Ken Sinn

Back to FHIR Consent Directive Project Main Page

Agenda

1. Agenda Review, Attendance, Approve FHIR CD April 29 Meeting Minutes
2. Updates to FHIR Consent proposals
3. Itemization opportunities via the FHIR chat. (e-mail from John to CBCC listserve)

The FMG will be held on Wednesday, 4:00 ET; see HL7 conference FMG working group meeting to find connection

different between consent racter vs consent directive. mohammod has offered to along with updated consent profile; we can look at both proposals both side-to-side

M: consent tracerk in the build JM; can take the information Kathleen will have Mohammed place the information in the build. Paul will have the information in for time for the FMG meeting with assistance from Mohammed

JOhn will be presenting consent resource (proposal) input; for the upcoming FMG meeting

Two proposals will be presented.

itemization opportunities via the FHIR chat. [chat.fhir.com FHIR chat link]

* FHIR Consent Resource - Improvement opportunities
** Rename Consent to PrivacyConsent (See Grahame email)
** Question domain an location? Are these needed? how do we make them more clear?
*** should jurisdiction be just a code (See Lloyd email)
** Cleanup introduction text: "consuming system", (See Adrian email)
** change Consent.type to a coding not a CodeableConcept (See Grahame email)
** remove Consent.action at the root as it is not logical, (See Tarik and Grahame emal)
*** Argument that at the root level the action is embedded in the Consent.type code.
** Add support for exception based on security_labels (See Mohammad thread on chat.fhir.com)
** Add clarity on Policy background (see Glen email)
** Add clarity on multi-generation plan scopes (see Glen and other emails)
** Add clarity on exception context vs exception data -- See Lloyd and Tarik
*** Add another element for context? Or explain how except.data is used base on except.code
** Add clarity to Consent.type (See Tarik email)
** Discussion of Consent resource with single layer of exceptions, vs Consent resource with only one layer (many resource instances) -- See Tarik email
** Is Consent.type should include the same codes as Consent.except.type?
Did I miss any improvement opportunities that have already been stated? I know there are more to come...  :-)

• FHIR Consent Resouce - Improvement opportunities
  • Rename Consent to PrivacyConsent (See Grahame email)
  • Question domain an location? Are these needed? how do we make them more clear?
    • should jurisdiction be just a code (See Lloyd email)
  • Cleanup introduction text: "consuming system", (See Adrian email)
  • change Consent.type to a coding not a CodeableConcept (See Grahame email)
  • remove Consent.action at the root as it is not logical, (See Tarik and Grahame emal)
    • Argument that at the root level the action is embedded in the Consent.type code.
  • Add support for exception based on security_labels (See Mohammad thread on chat.fhir.com)
  • Add clarity on Policy background (see Glen email)
  • Add clarity on multi-generation plan scopes (see Glen and other emails)
  • Add clarity on exception context vs exception data -- See Lloyd and Tarik
    • Add another element for context? Or explain how except.data is used base on except.code
  • Add clarity to Consent.type (See Tarik email)
  • Discussion of Consent resource with single layer of exceptions, vs Consent resource with only one layer (many resource instances) -- See Tarik email
  • Is Consent.type should include the same codes as Consent.except.type?

Did I miss any improvement opportunities that have already been stated? I know there are more to come... :-)

• should jurisdiction to just a code (see Lloud email)
  • discussion about a pointer to the location resource to identify a jurisdiction
  • use case is to define a jurisdiction

Use case: we hav a client who's jurisdiction that's cut an dpast (little here a little herer) so there is no easy way to say the location is 'X' ... its part of city Y, partly here... but we can't really use a single location, because it covers multiple locations (but we are talking about the EHR),

• • we can find a location ... that sounds like a problem to patient admin to determine (they own location resource)
  • would be willing to have a codeable concept

tasked should be forwaded to Patient Admin, as they own the location resource

• use case: IRB (from Glen)
• bring forward a set of use cases to present to Patient Admin which might challenge the location resource.
• in the case of a specific research project; theywould have their own consent type (pre-cpprdination--location, action which are coordinated in the type of consent); they are free to not use the domain or location element; more fundamentally;
  • this might even speak to the provenance of the consent (authority and domain element were in set for the provenance of the consent)

any problems with moving ... to consent resource

• Graham has suggested to call Privacy consent directive (as a resource)
• kathlyeen yes, and it should be operating as the 80% ...
  • privacy consent vs consent to treat...(including advance directives, etc) ALTHOUGH, if the structure is the same, consent should be considered.

Meeting adjourned at 1005 PST--Suzannegw (talk) 13:05, 3 June 2016 (EDT)

why is FMG asking