...
If the terms of the agreement are changed, we will need re-visiting users to re-consent to the new version of the agreement.
Status current consent(s)
| Status | ||
|---|---|---|
|
to be returned as part of the User Profile? Gaspar to expandThe consumers need to know which consent and which is the consent status. That information is stored in the Consent resource.
I know is desirable to have the information of the Patient and the consent status doing a single request to our system.
Talking about this, Moses Njenga suggested having an additional attribute in the response indicating that information. It’s a good solution and probably we need to implement that, but, before doing that, and trying to optimize time and effort, I suggest getting the benefits of the HAPIFHIR requests and using one of these queries:
Get the Patient and all his consent resources:
{{server}}/fhir/Patient/?_id={{PatientId}}&_revinclude=Consent:patient
http://openhim-dev.psi-mis.org:5001/fhir/Patient/?_id={{147}}&_revinclude=Consent:patientGet the Patient and all his consent resources with active status :
{{server}}/fhir/Consent?status=active&patient={{PatientId}}/147&_include=Consent:patient
http://openhim-dev.psi-mis.org:5001/fhir/Consent?status=active&patient=Patient/147&_include=Consent:patient
Both queries return a bundle request with a resource list. We only need to identify each resource by its resourceType and check the Consent status and name to know which information we need.
The Consent status could be: active | inactive. FHIR let us have more status, but I think these status values are enough.
Context:
Project: for query project as per header value
Type: T&C, Data Privacy, etc
Returned value: Status of the consent: active | rejected | inactive
...
When an agreement comes to an end, the project will need to run a mass update for all consent by doc ref number anid, and then:
Set status to:
inactive(see valueSet)Set end date of consent.period: date that the previous agreement was replaced by a new one (in FHIR v5, there is a
periodfield)
Re-consenting
When a user revisits a bot, and his/her consent is ‘inactive’ the bot will ask users to agree to the new T&C/data privacy agreement. This new acceptance is to be stored as a new Consent - FHIR resource, referring to the latest version DocumentReference - FHIR , setting the period/start date set to the date of the interaction.
...