Stream: implementers
Topic: Google Cloud Healthcare profile validation support
Paul Church (Feb 18 2021 at 17:56):
In case anyone is interested, we have now launched FHIR profile validation in the Google Cloud Healthcare API to public preview. StructureDefinitions and other related artifacts loaded into a FHIR store can be evaluated through the $validate method or the store can be configured to validate all incoming resources during create/update and reject any that don't conform to an enabled IG. https://cloud.google.com/healthcare/docs/how-tos/fhir-profiles
Ashish_N (Feb 20 2021 at 11:03):
Hi Paul - can you share any reference doc for Google's Consent Management API? I wanted to see if it checks for patient's consent to see what information is allowed.
Paul Church (Feb 20 2021 at 19:07):
There are a set of guides for the consent API, the one related to making access determinations is: https://cloud.google.com/healthcare/docs/how-tos/consent-access-determination
Methods related to checking consents include: checkDataAccess [reference] which checks if a specific data element is consented for given attributes, evaluateUserConsents [reference] which checks all data elements for a specific user that are consented for given attributes, and queryAccessibleData [reference] which is a long-running operation that returns all data elements that are consented for given attributes.
At the moment this is a component that would be built into a larger solution; the Consent API does not automatically control access to other stores in the Healthcare API.
Ashish_N (Feb 21 2021 at 18:13):
Thanks Paul. I'm trying to achieve one simple scenario in which I'm facing some difficulty and would request your help on this.
Lets suppose Patient provided his consent to one Practitioner to view his medical history.
In checkDataAccess I am passing dataId and request_attributes (which says practitionerId='abc'). My question is - do I need to store Practitioner's Id in Consent (under authorizationRule) along with REQUEST attribute definition allowed_values? It is throwing error when I'm not storing practitionerId in REQUEST attribute definition allowed_values. If I store then it works but the problem is allowed_values has limitation of 100 values. So, how should I handle this scenario?
Thanks
Paul Church (Feb 24 2021 at 22:21):
What you're describing is more of an ACL scenario where the "attribute" is the identity of a specific practitioner. The Consent API is intended for ABAC use cases where a practitioner may have some attribute like "directly responsible for the patient's care" (as determined by some business logic) and the patient's consent is for requests with that attribute to be allowed access.
Last updated: Apr 12 2022 at 19:14 UTC
