Wondered whether anybody has created “generic” patient consent resource profile capable of carrying consent/dissent assertions for different domains (e.g. SCR, care.data, IDCRs)?
Am currently having a look at https://www.hl7.org/fhir/contract.html but bamboozled by the number of fields!
Cheers
Sorry, I’m not going to help with the first question and have also got stuck before on the second one.
I would suspect the bamboozling originates comes from http://wiki.ihe.net/index.php/Basic_Patient_Privacy_Consents
and the problem is our models differ greatly from US (HL7/IHE) versions.
Hi Jonny!
This is a current debate:
http://wiki.hl7.org/index.php?title=FHIR_Consent_Directive_Implementation_Guide http://healthcaresecprivacy.blogspot.co.uk/2016/05/fhir-consent-as-resource-or-profile.html
This has led to a proposal for a Consent resource here (from Monday, so not even a draft 
):
Does this proposal work for those cases? On quick inspection it looks better than Contract …
Excellent - thanks both!
I shall do some reading and see how it works for commonly expressed consent preferences in the UK.
Cheers
Jonny
Hi chaps,
Through some NHS Scotland SCIMP work we created a ‘Consent to share’ archetype which captures some of the GP-data sharing consents needed in UK, as currently these are a mess and based on very arbitrary use of Read codes and internal flags. Might help in terms of gathering use cases appropriate to the UK. I will ask some of the other involved in that work (and looking at other approaches) to join in here.
http://clinicalmodels.org.uk/ckm/#showArchetype_1051.32.189_MINDMAP
Ian SCIMP Consent Archetype Nov 2013.pdf (696.9 KB)
Thanks Ian!
+1 to ‘a mess’.
I suspect that consent is an area where a greenfield approach is necessary, rather than trying to build on the existing foundations.
Interestingly, there is a current consultation with GPSoC suppliers about a new set of formal requirements around data sharing for direct care. Conceptually, this is based around org-org data sharing agreements into which patients can then opt-in/opt-out. This would give us the exciting new possibility of a patient being able to be simultaneously opted-in to one ‘national shared electronic record’ and opted-out from another ‘national shared electronic record’ 
The context of the original SCIMP work went beyond that into data-sharing for secondary use in connection with SPIRE (Scottish approach to care.data) and to include ad-hoc requests for research groups. We showed the draft archetype/mindmap to Julia Hipsley-Cox and she felt that something of that nature would help those groups as well.
Just to be clear - don’t care much if/ how we use openEHR/ FHIR or both to nut this out, and on a quick perusal the proposed FHIR model looks pretty good and well-aligned with our thoughts. We just need folks to understand that it is not just a case of throwing more READ/CTV3 orSNOMEd codes at the problem, which is the current horrendous approach.
The key as @dunmail says (and reflected in the SCIMP presn.) is that it should allow patients (if they so wish) to manage their own preferences, though that might need the addition of some broad consent default patterns to simplify setting preferences.
Ian
on tech side I’d probably want a service that I could answer questions like:
Dr smith, a cardiologist @ somewhere trust would like to access patient jones medical record to provide care
Social worker mr brown would like to view mr Jones care plan to provide care.
Mrs smith would like to access her husbands record to assist providing care
Abc organisation would want to access a subset of mr Jones medical record for research.
Etc
possibly could break down the questions into more detail but that’s a level we could support at the mo.
Thanks Ian and Kev
So I checked http://healthcaresecprivacy.blogspot.co.uk/2016/05/start-at-consent-as-fhir-resource.html and at 6.7.3 the general model is not unlike this: another version of the required content to specify consent to share includes
· accessor e.g. patient / carer / advocate, clinician; NHS admin;
· purpose e.g. direct care, indirect care, secondary uses
· processing e.g. sharing to view / to process e.g. edit, aggregate, pseudonymise
· location e.g. locally only / other Accredited Business System / within NHS / view by pharma research / by Govt / open viewing
· time e.g. this encounter only / within clinical episode / for 1 mo / expiry date / indefinite
· clinical e.g. “emergency” overrides
Any combinations would need processed to produce a status to control the actual sharing of data i.e.
· consent / dissent / unknown / override with pt aware/unaware
(Clinical note: we found that overriding of pt. dissent may be required for end-of-life care planning, that can go on for months with variation in awareness of either the pt. or their advocate)
Common combinations to form use cases can follow those examples for US and Canada in that blogspot post.
I think some of this content is carried in IHE’s Basic Patient Privacy Consent profile, and I learned at eHealth Week that most of the Netherlands’ and some of Belgium’ hospitals use BPPC to automate consent management – seamlessly for clinicians – at last!
I also heard there that NHS Digital are planning a central consent management service?
Sorry this is just a text list: hope it can be processed in whatever technology you guys prefer?
Colin Brown MB MBCS FRCGP
Glasgow
Clinical Informatics Adviser
SCIMP
All
Not much to add other than to re-iterate the clear business requirement for this piece of technology.
Like Ian not fussed whose modelling paradigm gets used for it but politically consent is such a sensitive issue that being able to have good collaboration from all the users - including the citizens whose consents are being modelled - would be vital. We ran into the ground in this in NHS Scotland because they could not identify a customer for the project, which is a local consequence of the organisation of eHealth here. Developing the model then making it available and implemented in real world systems is something of a project which without some sort of ownership and customer is difficult to make happen.
Interesting that you’ve had problems getting this modelled and implemented in practice - we see the same in England.
At the moment, data sharing is focussed on sharing between existing organisations. Unfortunately, the real world is not so tidy! There is a network of relationships between organisations, professionals and citizens.
To deal with this we have to provide 2 components. First, we need to establish identity, so can reliably establish which entity we are talking about. For professionals this could be built on top of existing registers (e.g. Spine RBAC), for citizens this look something like Verify (https://www.gov.uk/government/publications/introducing-govuk-verify/introducing-govuk-verify). Once we have identity then we can look at the individual relationships and start to define rules and behaviours for each relationship.
Unfortunately, I can’t see how the current procurement models would every allow us investment in this (crucial) part of the infrastructure!
CONSENT
Spoken about this before on other forums , but the consent area is not as green field as it looks - take a look at the Apple model of consent for data sharing. This is not based on organisations or individuals having access to a whole data set, but rather allows ‘applications’ to access ‘personal types of data’.
Nice to see some consent models being presented here though but they appear too granular for the accessors: individuals and organisations ; not granular enough on the data types being accessed too focussed on legalities.
I like the Apple model, because 
1 - it is activated immedately on the push of a button by the patient
2 - it allows for granularity of different datatypes - ok maybe not quite granular enough
3 - it is focussed on providing consent to 'services and applications’ which makes legal obligations and implications on data handling flow through whoever is commissioning and providing these apps and services.
It is also comparatively easy to implement a consent register of healthcare applications , to provide integration to smartphones to support patient consent gathering and to implement/police these consent instructions.