...
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 | ||
|---|---|---|
|
The 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.to be returned as part of the User Profile? Gaspar to expand
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.
...