hi all… here is a draft document that circulated around the IL group a few months back re: consent management. it is a work in progress… but lays out the issue and a few options for addressing it.
derek.
15-04-13 OpenHIE Consent – draft for discussion v0.1.docx (820 KB)
Derek Ritz, P.Eng., CPHIMS-CA
ecGroup Inc.
+1 (905) 515-0045
www.ecgroupinc.com
@dritz this is an excellent introduction to the situation and challenges. Well done.
@jennifer.e.shivers I think we should consider inculcating consent management into our privacy discussions.
Thanks, @jstclair – that’s very kind. It’s a shame the conversation really didn’t get much uptake at the time (wow… SEVEN years ago!). I still believe option-1 (implied consent, all-in / all-out, no BTG) should be our go-to as the “minimum” needed. Even with no BTG, it is a useful and implementable step forward. I recommended it at our OpenHIE Architecture committee… and even went so far as to propose development of a paper-thin IHE Profile work item… but (sadly) no takers.
Hi there! Happy New Year! What are our next steps?
HNY @jstclair – I hope you had a restful and rejuvenating holiday break. 
My sense is that the smart next steps would be to document a required (conformance-testable) IL behaviour that operationalizes a default consent profile. As I noted above, I would advocate for option-1 as our default. This would mean that, unless consent is explicitly withdrawn, all health data will be shared with all authenticated health workers with no support for provider BTG (break the glass).
Of course – as an important corollary – we must also define how patient consent for data sharing would be withdrawn. I think a single FHIR consent resource could serve as a flag to operationalize, for an identified patient, the “I have withdrawn my consent to have my health data disclosed” directive. Sadly, unlike in HL7v2, there is not a data element in the FHIR patient resource that can serve as a simple consent yes/no flag. This means an extra fetch from a FHIR server (maybe the CR??) will be necessary in order to see if consent has been withdrawn for this patient.id… and this will entail a non-trivial performance “penalty”. This performance penalty may prove to be a dealbreaker in production systems, in which case alternatives may need to be explored (extensions… multi-resource fetches… other approaches?).
Sorry this turned into such a long post. 
Hello. I think having this conversation at either / both the privacy and security community ( @bobj @austin ) and the interoperability sub community (@ryan ) would be great.
I am wondering if there is a specific country or context need as I suspect that implementation may be different based upon requirements.
Since the consent resource on FHIR is there to determine a consent, I feel that adding an extension would be an anti-pattern IMO.
As one of the use cases for the consent resource is
Medical Treatment Consent Directive: Consent to undergo a specific treatment (or record of refusal to consent).
If the performance penalty is significant, I think one way in FHIR is to perform a batch request and get both consent and patient resources from a single request.
@ruky @dritz Sorry for my late reply, and love this conversation. We are having discussions in the US right now in NY and California about consent, to include non-clinical factors. I wholeheartedly agree in some demonstrations, and this we have the FHIR consent resource, the IHE Privacy and Consent Profiles, and even technical considerations of FHIR as a JSON object and using policy as code for consent.
Do we have a proposed meeting on the calendar, or perhaps a Task Group?
@dritz @jstclair Yes agree that consent resource is the way to go and using a method to fetch both consent and patient resource in a single request. Would love to join a discussion
I would recommend we bring this up with the Client Registry community. As a practical matter, if we expect to do a batch-fetch of patient demographic + consent “flag” content, we will be well-served to design in such a way as to avoid making a cross-server request. @sgrannis @lduncan
To be clear – the assumption that a person-centric consent flag is to be retrieved from the CR quite narrowly scopes our use of this resource. consent can be associated with resources well beyond just the patient resource. Also – to only use the resource to denote when consent has been withdrawn is also a narrow scoping.
I agree with @ruky that this is the right way to go. That said, these are non-trivial issues that may well warrant broad discussion within the FHIR and IHE communities. Just a thought…
There is a current work item in IHE ITI related to consent and FHIR:
http://build.fhir.org/ig/IHE/ITI.PCF/branches/master/volume-1.html
This is currently being worked on and isn’t in the public comment stage yet. There are regular calls on this work item and I can bring up any particular issues there or let me know if anyone else would like to join.
The existing related profiles are:
BPPC: IHE ITI TF Vol1
APPC: https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_APPC.pdf
Hey everyone, we’ve had several policy and architecture developments on consent in the US, and maybe a time to re-convene? Feel free to tell me is I missed any meetings already