NHS England North West GMSA - IHE Laboratory Testing Workflow (LTW)
0.0.1 - ci-build United Kingdom flag

DRAFT Implementation Guide

This is for collaboration and discussion purposes and is subject to change.

NHS England North West GMSA - IHE Laboratory Testing Workflow (LTW) - Local Development build (v0.0.1) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Authorisation (OAuth2)

Is based on IHE Internet User Authorization (IUA) but using client-credentials grant only (at present).

The authorisation will be hosted on the Regional Integration Engine. This is responsible for maintaining all the clients for the region.

Any Trust Integration can act as the Authorisation Client or Resource Server in the diagram below.

Client CredentialsAuthorisation Client(Trust Integration Engine)Authorisation ServerResource Server(Trust Integration Engine)optAuthorisation Server Metadata Request (ITI-103)GET {baseUrl}/.well-known/openid-configurationMetadata ResponseGet Access Token (ITI-71)Get Access Token RequestPOST {baseUrl}/tokengrant_type=client_credentials&scope=system/*.*Access Token ResponseRequest (e.g. POST {baseUrl}/$process-message)HTTP Header: authorization contains Access TokenIntrospect Token (ITI-102)Introspect TokenPOST {baseUrl}/introspectValidate TokenIntrospect ResponseResponse

OAuth2 - Client Credentials Grant


  • Authorisation Server Metadata Request (ITI-103) is an optional step to retrieve the metadata for the Authorisation Server
  • Get Access Token (ITI-71) is used to obtain the Access Token, the request uses basic authentication using the client id as username and client secret as the password.
  • The client then performs requests to the resource server using the Access Token (authorisation = Bearer {accessToken})
  • The resource MUST check the token is valid using Introspect Token (ITI-102), invalid tokens will be rejected using a 403 Forbidden http code.

At present the authorisation server does not support a refresh token or endpoint.