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

Use Cases

Use Cases

This Implementation Guide provides profiles that support the tracking of user consent to share data from a data holder to a third party applicaiton or service. The user authorizes the sharing of their data by exercising their HIPAA right of access.

The expected use of this IG is to record the authorization of data sharing as part of an OAuth2.0 or SMART-on-FHIR interaction with a data holder’s FHIR APIs.

The following use cases are documented in this IG:

  1. Consumer-Controlled Application is registered with Data Holder.
  2. User with a digital account with the Data Holder authorizes sharing with a registered application.
  3. User with a digital account with the Data Holder revokes the authorization to share with the registred application.
  4. User with a digital account with the Data Holder requests a list of current authorizations to share
  5. User with a digital account with the Data Holder requests a list of all authorization to share including expired or revoked authorizations
  6. User grants access to their data to another person (family member, caregiver, practitioner etc.)

Consumer-Controlled App Registration

An authorized representative of a Data Holder approves the registration of a Consumer-Controlled App.

When an App is registered three resources are created:

  • An Organization resource that defines the developer’s organization.
  • An Endpoint resource that describes the interface information for the developer’s application.
  • A Consent resource that describes the data sharing use case that the application is approved to participate in.

There should also be an Organization resource that identifies the Data Holder.

The approval of an application by a data holder will generate a client secret and client key. This should also generate the consent resource that records the approval of the app for a specific set of api calls and permissions.

The Data Holder will issue two consent transactions relating to an App registraiton:

  1. Create Registration approval
  2. Terminate Application Approval

An App can have multiple registrations that provide different access permissions. For example, a consent record for each Implementaiton Guide set of APIs.

Examples

  1. Create Registration Approval: See SafhirAppRegByDataHolder for an example of an Application Registration recorded as a Consent resource.

  2. Terminate Application Approval: See SafhirAppRevokeByDataHolder for an example of a data holder revoking access for a third-party application.

Consumer Authorizes Sharing with Registered App

A consumer uses a registered app to access the FHIR API and after authentication the consumer authorizes their data to be shared with the app.

A Consent resource is created that links the following resources:

  • Patient resource
  • Data Holder Organization resource
  • Endpoint resource
  • Consent resource

There are two consent transactions used when a consumer interacts with a registered app:

  1. App Consent record is CREATED to record permissions granted
  2. App Consent record is UPDATED to record permissions inactive.

A consumer consent record is not deleted. Instead the status is updated to cancelled.

Consumer Revokes Sharing with Registered App

A consumer uses a portal provided by the Data Holder to revoke sharing of data with a registered app.

The Consent resource is updated to record the time and date of revocation. The status of the consent is marked as inactive. The provision.period.end date is changed to the date and time of revocation.

Consumer Requests List of Apps Receiving Data

A consumer uses a portal provided by the Data Holder and requests a list of apps that are currently permitted to share the consumer’s data.

A search is made that identifies all active Consent resources for the Patient.

TODO: Search query

Consumer Requests History of All Authorized Apps

A consumer uses a portal provided by the Data Holder and requests a complete history of all authorizations they have made to share their data.

A search is made that identifies all active and revoked Consent resources for the Patient.

TODO: Search query

User grants access to their information to another entity

This use case uses the Consent resource to record the granting of access to a user’s health information by another person or entity.

The Consent resource can also be used to record when a user’s health information is refused to be shared with another person or entity.

A consumer uses a portal provided by the Data Holder and records their decision to consent to share their health information with another person or entity.

A consumer may also record their decsion to prevent a user from accessing their health information.

The creation of the relevant consent record can also be performed by an authorized person acting for the data holder, such as a member of the privacy or compliance department. This would typically be performed in response to enrollment or individual data access requests received by the data holder, such as when a request is received from a person with Power of Attorney for the member.

There are two transactions used to record when a consumer defines access permissions for another entity:

  1. A conumer declares a grant or deny decision for access to their health information.
  2. A consumer withdraws the prior decision for access to their health information by setting status to inactive.

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.):