Consent Status and Re-consent - FHIR

Each client needs to agree to a set of (1) Terms and Conditions (T&C) and (2) a Data Privacy agreement when they have a direct interaction with us. This consent is in most cases collected by the chatbot at the beginning of the interaction, for which we create a Consent - FHIR resource relating to the Patient and an specific DocumentReference - FHIRresource. The Document Reference resource captures the exact details of such agreement, as it contains a PDF with the specific terms.

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)

under desing

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.

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:patient
  
  

• Get 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

Expiration of current consents

When an agreement comes to an end, the project will need to run a mass update for all consent by doc ref id, 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 period field)

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.