Onyx Consent Authorization SAFHIR Implementation and Operations Guide
0.0.2 - ci-build
Onyx Consent Authorization SAFHIR Implementation and Operations Guide - Local Development build (v0.0.2). See the Directory of published versions
Oauth2.0 Consent Authorization Systematic Input Output (OCASIO)
The SAFHIR Consent IG documents how an OAuth2.0 Authorization can be stored as a FHIR Consent resource, using the SafhirConsent profile.
The Consent resource will be created when an authorization is created by an authorized entity. That entity could be a user(Patient), an organization or a system (Endpoint). It will be updated when a revocation is issued by an entity.
A Contract resource can be used to document the acknowledgement of a third-party developer accepting the terms and conditions to access an API/Implementation Guide.
The following diagram depicts the relationship between the consumer, data holder and the applications or services being granted access to the user’s data.
|
Health Plans have a requirement to enable members to give permission to delegate representatives to be able to access their health records. There is no recognized standard that defines the process for granting these permissions and communicating those permissions to the API platform and third-party applications accessing the platform.
Onyx and the SAFHIR platform are defining the process for delegated consent.
A Health Plan member can grant or deny permission to another individual to access their health data. Granting access to an individual is not inherited to another individual.
The following diagram depicts how a consent resource can be used to authorize or prohibit the sharing of data between the user and another entity (related person, practitioner, caregiver, organization, etc.):
|
Six use cases have bene identified. They are covered in the Use Cases page of this guide.