Stream: implementers
Topic: Consent Constraints
Ramandeep Dhanoa (Jun 24 2020 at 18:02):
Hi @Lloyd , I am trying to understand Consent constraints applied through provision element. We have following scenarios which I am trying to map in Consent resource:
1. Patient giving consent to access their Lab, Rad and Transcribed documents
2. Patient giving access to Lab and Rad, but not Transcribed
3. Patient withdrawing consent to disclose Lab, Rad and Transcribed.
Any suggestions?
Also, I have been also looking at Consent resource example ‘Withhold or withdraw consent for disclosure of records related to specific domain (e.g. DI, LAB, etc.)’
https://www.hl7.org/fhir/consent-example-notThis.json.html
Are these specific domains (DI, LAB, etc.) are represented in the example through provision.data element?
Lloyd McKenzie (Jun 24 2020 at 19:50):
@David Pyke
David Pyke (Jun 24 2020 at 20:46):
The data can be blocked via a deny and then listing the types of data via LOINC or SNOMED (or other) codes in provision.code and/or using specific resource types in provision.data.reference and then selecting related as provision.data.meaning E.g., information related to a specific Encounter, etc. If you're trying to block all Lab or all Radiology information, that would be difficult. We didn't see that an entire type of information would be needed. That may be something we need to examine if your use case is that broad.
Ramandeep Dhanoa (Jun 25 2020 at 18:27):
Thanks @David Pyke I am thinking we could use LOINC or SNOMED, or other codes - to represent the data (or its category). But how to represent both deny and permit in a consent, for example - Patient giving access to Code1, Code2, but not Code3. Provision cardinality won't allow that..
David Pyke (Jun 25 2020 at 18:28):
It will, through nested provisions. The provision element is a tree structure so you can set a base Permit/Deny in the root provision and then have exceptions in sub-trees.
Ramandeep Dhanoa (Jun 25 2020 at 21:09):
Ahh got it. Thanks :)
Last updated: Apr 12 2022 at 19:14 UTC
