FHIR Chat · Where to map denial reason for Consent? · implementers

Stream: implementers

Topic: Where to map denial reason for Consent?


view this post on Zulip Maria Hu (Oct 10 2019 at 00:14):

Two questions re: resource Consent:

  1. Resource Consent.provision.type has a possible value of 'deny'. If I want to capture the reason for denial, where in the resource is the best place to do so?
  2. If I want to capture comments about a particular consent, where in the resource is the best place to do so?
    Appreciate if someone can advise, thanks !

view this post on Zulip Lloyd McKenzie (Oct 10 2019 at 02:09):

@David Pyke

view this post on Zulip Jose Costa Teixeira (Oct 10 2019 at 03:52):

Consent being a voluntary and free thing to give, I'm curious about why we'd need 'reason for denial'. The patient should not need to provide a reason. Do you plan to use that reason for anything? Just wondering about the requirements behind this.

view this post on Zulip Lloyd McKenzie (Oct 10 2019 at 03:55):

It may point to areas where the "informed" part of the consent could be improved or to changes in what the patient is asked to consent to.

view this post on Zulip Lloyd McKenzie (Oct 10 2019 at 03:55):

(Same sort of reason public health captures reasons when someone refuses an immunization)

view this post on Zulip David Pyke (Oct 10 2019 at 11:16):

Information regarding reasons why and all other information for use by humans is captured in the documentation attached as Consent.source.

view this post on Zulip John Moehrke (Oct 10 2019 at 12:29):

we could put a reason string on each provision, but I don't think it is realistic that a patient will express that specifically, nor is it critical to the processing of each provision. The reason can easily be captured in the .source element. (this said, no one has brought forth a need for a reason string.)

view this post on Zulip Maria Hu (Oct 10 2019 at 19:53):

Consent being a voluntary and free thing to give, I'm curious about why we'd need 'reason for denial'. The patient should not need to provide a reason. Do you plan to use that reason for anything? Just wondering about the requirements behind this.

Yes, like what Lloyd has pointed out, we are using the resource Consent for CONSENT DIRECTIVE in the context of refusal to immunization.
An example of the refusal reason can be Parent/Guardian Refusal.
Currently the consent.source element has the datatype of attachment or reference another resource, either way is not applicable to capture the refusal reason and comments.
Any other suggestions please, thanks.

view this post on Zulip Craig Newman (Oct 11 2019 at 17:30):

If this is just for immunizations and the only thing really being captured is the codeable reason for not performing the immunization, the Immunization resource itself can be used to capture immunizations not done (Immunization.status = not-done) with the coded reason in Immunization.statusReason. Not sure if that would be sufficient for your needs or not.

view this post on Zulip Maria Hu (Oct 16 2019 at 19:38):

If this is just for immunizations and the only thing really being captured is the codeable reason for not performing the immunization, the Immunization resource itself can be used to capture immunizations not done (Immunization.status = not-done) with the coded reason in Immunization.statusReason. Not sure if that would be sufficient for your needs or not.

Thanks Craig, YES, that will work !!


Last updated: Apr 12 2022 at 19:14 UTC