Provider Identifier Access Restriction

See the "User Access" chapter of the Security Guide for details of this type of access restriction. The HTTP API only exposes provider identifiers to which the user has access.

Restrict Top-level Resource

Use case

A provider identifier is retrieved as top-level resource.

The user can retrieve the restricted provider identifiers as normal, but the identifier attribute returns no value when the corresponding identifier type is access restricted.

Restrict Sub Resource

Use Case

A top-level resource is retrieved with identifiers as its sub resource.

The HTTP API does not filter out the provider identifiers. Instead, it conceals the identifier attribute on the provider identifiers that belongs to the identifier type to which the user does not have access.

Concealing of Linked Resource

The HTTP API does not support this case. Identifiers do not act as linked resources, they can only act as top-level or sub resources.

Inference Prevention

The HTTP Query API supports searching for providers based on their identifiers:

POST http://[hostName]:[portNumber]/[api-context-root]/generic/persons/search
{
  "resource": {
    "q": "providerIdentifierList(+).identifier.eq('123-34-5456')"
  }
}

When a provider identifier is used for finding a provider (and that provider exists), but the identifier type of the matching provider identifier is restricted, then it is inferred that the person is not returned.

In other words, when searching for providers based on a provider identifier, the query ignores provider identifiers that belong to an identifier type to which the user does not have access. The HTTP Query API automatically applies a filter when a provider identifier attribute is used as query condition.

This restriction does not apply when searching for providers without any provider identifier search criteria.