Healthcare Provider Directory Access Control
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:
- Practioner
- Practioner 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}
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
- IETF: The OAuth 2.0 Authorization Framework
- IETF: The OAuth 2.0 Authorization Framework: Bearer Token Usage
- IETF: OAuth 2.0 Dynamic Client Registration Protocol
- IETF: OAuth 2.0 Token Exchange
- IETF: OAuth 2.0 for Browser-Based Applications
- Spring docs: Implementation Guidelines for Browser-Based Applications
HL7
- HL7: Implementation Guide
- HL7: FHIR NPM Packages
- AU Core: Publication (Version) History
- AU Core FHIR Implementation Guide: AU Core - 1.0.0-preview
- AU Core FHIR Implementation Guide: Testing FAQs
- Sparked AU Core Test Data: Postman collection
- HL7 AU: Australian Provider Directory Implementation Guide
Keycloak
- Keycloak docs: Configuring Keycloak for production
- Keycloak docs: Configuring TLS
- Keycloak docs: Configuring trusted certificates
- Keycloak docs: Configuring the hostname
- Keycloak docs: Using a reverse proxy
- Keycloak docs: Running Keycloak in a container
- Keycloak docs: Migrating to the Quarkus distribution
- Keycloak docs: Upgrading Guide - 26.1.0
- Keycloak docs: Authorization Services Guide
Keycloak-based Development
- GitHub: Keycloak Project Example
- GitHub: Awesome Keycloak
Keycloak Support
- Google Group: Keycloak User
- Google Group: Keycloak Dev
APISIX
- APISIX docs: Deployment modes
- APISIX docs: SSL Protocol
- APISIX docs: Certificate
- APISIX docs: Plugins - OpenID Connect
Provider Directory
- HAPI FHIR: Website
- HAPI FHIR: Documentation
- Google Group: HAPI FHIR