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.
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?).
@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?
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…
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.