Rob Ferguson

Healthcare Provider Directory Access Control

Rob Ferguson -

Introduction

In the Australian context, a healthcare provider can be defined as an individual or organisation involved in the delivery of healthcare services.

This broad definition encompasses a range of individuals, including doctors, nurses, and other health professionals, as well as organisations like hospitals, clinics, and aged care facilities.

Individual Healthcare Providers

These are individuals who provide, have provided, or are intending to provide healthcare services. This includes registered health professionals such as medical practitioners, nurses, dentists, pharmacists, and allied health professionals.

Note: Individual healthcare providers are also referred to as healthcare practitioners.

Organisational Healthcare Providers

These are organisations that deliver healthcare services. Examples include hospitals, day procedure centers, aged care facilities, and pathology or radiology services.

Healthcare Identifiers

Healthcare Provider Identifiers (HPI-I and HPI-O) are used to uniquely identify individuals and organisations involved in the delivery of healthcare services.

Healthcare Provider Directory

A healthcare provider directory is a repository of information (where data is stored and maintained) about healthcare providers.

FHIR Resources

There are a number of provider-related FHIR resources.

For example:

  • Practitioner
  • Practitioner Role
  • Organization
  • Healthcare Service
  • Location

Note: As per the FHIR specifcation, the spelling of FHIR resource names (like "Organization") follows the American English standard.

FHIR Operations

FHIR operations are interactions defined by the FHIR standard for manipulating healthcare data. They follow a RESTful paradigm, allowing for Create, Read, Update, Delete (CRUD) and Search actions on FHIR resources.

For example, to read Organisation information:

GET /Organization/{id}

SMART on FHIR

SMART on FHIR defines OAuth 2.0 scopes that allow applications to request a specific set of access rights. The OAuth 2.0 client conveys this information to the authorization server in the form of a 'scope' request parameter.

The SMART on FHIR specification defines the structure of scopes, for example:

system/Organization.read
system/Organization.write

To enable an OAuth 2.0 client to read all the values from the Organization resource the client would include the system/Organization.read scope in its request to the authorization server.

A resource context prefixes each SMART on FHIR scope:

user
patient
system

This value represents one of three possible scenarios: user access to the resource is constrained by the user's access permissions; patient access to the resource is restricted to the in-context patient; system access is confined to system-based authorization workflows (e.g., the Client Credentials grant).

The following modification rights are defined:

read
write

Where read includes "search" and "history”. And, write includes create", "update and "delete".

Note: Keycloak does not support wildcard scopes, clients must explicitly request each scope they require.

Access Control

How do we define coarse-grained access control?

Coarse-grained access control is when access to resources is granted or denied based on broad, general criteria, often at the role (RBAC) level.

For example:

  • Responsible Officer (RO)
  • Organisation Maintenance Officer (OMO)
  • Authorised Employee
  • Individual Health Care Provider
  • Contracted Service Provider (CSP)
  • General Supporting Organisation (GSO)

How do we define fine-grained access control?

Fine-grained access control is when access to resources is granted or denied based on multiple conditions and may combine different access control mechanisms (ABAC, RBAC, ReBAC, UBAC).

In the Australian Healthcare context, support for fine-grained access control is often required.

For example, a Practitioner must be granted the Organisation Maintenance Officer (OMO) role and have a membership relationship with an Organisation in order to maintain Healthcare Service information on an Organisation's behalf.

We need an Authorisation Service that can provide fine-grained access control for FHIR resources in a Healthcare Provider Directory.

Authorisation Service

The Authorisation Service is comprised of the following components:

  • OAuth 2.0 Authorization Server (that supports the Client Credentials grant)
  • OAuth 2.0 Security Token Service (that supports the Token Exchange grant)
  • Policy Enforcement Point
  • Policy Decision Point

Keycloak supports the Client Credentials grant and the Token Exchange grant.

Policies are enforced by the API Gateway (APISIX).

Policy decisions (evaluation) are performed by the general purpose Policy Engine (Open Policy Agent).

Policies are authored in Rego.

Reference data (e.g., Roles, Permissions, Relationships) is loaded when the Policy Engine is healthy.

Policies are loaded when the Policy Engine is healthy and all reference data has been loaded.

Source Code

What's Next

In the next post, we'll take a look at Open Policy Agent. A general-purpose policy engine that you can use for policy decisions (evaluation) in API gateways, microservices and more.

References
OAuth 2.0
HL7
Keycloak
Keycloak-based Development
Keycloak Support
APISIX
Provider Directory