---
tags: CDEX
title: POU, Authorization and Scopes - OH MY!
---

# POU, Authorization and Scopes - OH MY!

## Scope:

Response to this tracker and proposed resolution:

[FHIR-30824](https://jira.hl7.org/browse/FHIR-30824)

Covers following topics: POU, Authorization Scopes, Direct Query, Task based requests, Bundles and Operations

## Background from Comments

**[CareEquality](https://confluence.hl7.org/pages/viewpage.action?pageId=131050960) Recommendation for exchanging purpose of use**

## Original Opinion:

The purpose of use that we're capturing here has different granularity than would typically be used when establishing a UDAP connection and certainly the purpose of use will vary for a given client after they've registered. Decisions about what information to provide (and whether to provide information at all) will be driven by the specific intended use of the information solicited.

Even when purpose of use was established when creating a UDAP connection rather than just initial registration, we don't think it's reasonable to re-establish a distinct session each time data is asked for. And if all possible purposes of use were established on connection, that wouldn't provide the specificity required - "What is the purpose of this specific data request?". The purpose of use may differ for different requests even when operating within the same patient session. In short, the UDAP layer isn't the appropriate place for the purpose of use that we need here.

## Opposing View:

### Key Points and Assumptions:

POU

- POU is negotiated between payers and providers via business agreements
- Payers and Providers use a broadly sweeping POU like "OPERATIONS" and "TREATMENT"
- Therefore what is value to a more fine grained valueset?
- A single POU per client at app registration is the current model.
- either through manually filling out a form or through dynamic registration like UDAP
- "Automated Declaration of Purpose of Use on Request" for either Direct Query or Task Based Approach is complex to implement properly thus increasing costs of implementation and the risk of failure.
- FHIR Data Segmentation for Privacy which is all about tagging the data and is not relevant of this discussion.

SMART Scopes

- Payer and organizational user access scopes are negotiated and documented via business agreements
- these scopes should be reflected in SMART scopes
- Scopes limit access no matter if done by direct query or returned as a contained bundle! (In other words, if you can't do a FHIR RESTful Search on a Patient's Obvservation, you can't get it via a contained Task Bundle.)
- Although Operations are treated separately in SMART scopes,in principle you don't get access to data whether the method is a pull or a push.
- therefore the Task contained bundle option is a convienence and not a work-around to not having the scopes!
- Payers are not inclined to perform Direct Query of FHIR resources

### New Proposal:

1. Change POU input element in the Task Profile from *Must Support* to *Optional* (pre-applied).

- update documentation:

from:

"Purpose of Use for the requested data is communicated between the Payer and Provider using codes from the CDex Purpose of Use Value Set in Task.input. Examples using these codes are provided below."

to:

The [CDex Task Data Request Profile]() defines an optional element that represents the purpose of use for the requested data with a fine grained [CDex Purpose of Use Value Set](). If this element is supported by the Data Source, its permits more find-grained Purpose of Use codes to be communicated dynamically in the individual Task based queries. This may be important when the purpose of use differs from the ‘default’ purpose of use for that data consuming system. It allows the The Data Source to make necessary decisions about whether to provide the information at all or whether/how to filter the information. The examples illustrate how this input element can be used.

2. Update the Task Based query documentation to avoid implication that this authorization is an oauths based process.

From

- Whether a specific Authorization is needed
- The Access to the data is limited (for example due to patient privacy concerns the data needs to be reviewed and/or filtered )

to

- The Access to the data is restricted and a specific authorization is needed (for example due to patient privacy concerns the data needs to be reviewed and/or filtered )

3. Update the *Security and Privacy General Considerations* section

From:

User scopes **SHALL** be used as defined in [SMART App Launch](#) to restrict access to the relevant patients for a given Data Consumer.

To:

User scopes shall be used as defined in [SMART App Launch](#) to restrict access to the relevant patients for a given Data Consumer. Organizational user access scopes are typically pre-negotiated and documented via business agreements. These agreements shall be translated into the appropriate [SMART App Launch](#) scopes.

4. Update *Security and Privacy Purpose of Use* section

From:

~~In some cases, it may be important to transmit the purpose of use when soliciting data. Specifically, when the purpose of use differs from the ‘default’ purpose of use for that data consuming system (generally ‘payment and operations’ for payers and ‘treatment’ for providers), the data source needs to be able to make decisions about whether to provide the information at all or whether/how to filter the information.~~

~~For the Task based approach, representing purpose of use is documented here. However, when using standard RESTful queries, such information cannot be conveyed directly. There is work in progress in FHIR SMART v2 (Granular Controls) and the FHIR Data Segmentation for Privacy (ballot version) on standardizing how this information can be conveyed using OAuth. Once a suitable approach has been agreed upon and published, it will be referenced in a future version of this guide. In the interim, implementers should consult with their compliance department to determine what requirements exist and how best to satisfy them, whether with in-band or out-of-band communications.~~

To:

The purposes for which data may be used by or on behalf of an organization is known as the Purpose of Use (POU). It is important part of data sharing agreement between Data Consumers and Data Sources because privacy policies and consent directives dictate the response to data requests. Common POU types are listed in the [NHIN Purpose Of Use Code System](http://hl7.org/fhir/codesystem-nhin-purposeofuse.html). A Payer's POU is typically "OPERATIONS" and a Provider's is "TREATMENT". A single POU is assigned for a client applications *when the app is registered*. either statically (e.g., manually filling out a form) or dynamically (e.g., [UDAP](#)). Therefore it is implicit when the Data Consumer makes a direct query or an "automatically fulfilled" Task to the Data Source using that app.

For Task based queries, the Purpose of Use for the requested data **MAY** be also communicated between the Payer and Provider for each Task using codes from the CDex Purpose of Use Value Set in the [POU Task.input element](X). If supported by the Data Source, it permits communicated a more fine-grained the POU at the individual request level and may even extend the POU from the ‘default’ purpose of use for that data consuming system.