Introduction

In the second phase of the project, the main purpose of the Unified Pathology Record is to consolidate Orders and results from the participant members of the West of England Pathology Network. Before we move on to that though, all of the concepts need to be proved in this proof-of-concept environment.

After you have submitted your data through your respective landing point, your HL7 v2 ORM and ORU messages are processed as per the diagram below.

Important : This service is only for proof of concept testing and as such no real patient information is permitted. The expectation is that any data submitted is from your TEST Systems only.

Please note: The guide below is intended to give a one page overview. Further materials are available in the West Of England Diagnostic Networks' SharePoint site

If you do not have access to the SharePoint site, please contact our support team.

Getting Started

Before you can submit any data to your respective landing point, you will need to get JWT authentication web tokens. Each Trust has a nominated landing point, and only the correct key will allow submission of data to that point. Your key will not work on the landing points for other Trusts.

If you are a TIE developer for North Bristol NHS Trust, Somerset Foundation Trust, or Gloucester Hospitals Foundation Trust, credentials have already been created for you to submit your HL7 v2 ORM and ORU messages to your own API data landing point.

If you do not have access to these, please contact our support team.

Get a JWT Auth Token

Now that you have your credentials, it's time to get a token. The OAuth 2.0 client credentials grant flow requires several key attributes to successfully obtain an access token. Here’s a description of each required attribute:

  1. grant_type:

    • Description: Specifies the type of grant being used. For client credentials, this must be set to client_credentials.

    • i.e. grant_type=client_credentials

  2. client_id:

    • Description: The unique identifier for the client application that is requesting the token. This is provided when you register your application with the authorization server.

    • Example: client_id=YOUR_CLIENT_ID

  3. client_secret:

    • Description: A secret known only to the application and the authorization server. It is used to authenticate the client application.

    • Example: client_secret=YOUR_CLIENT_SECRET

  4. scope (optional):

    • Description: Specifies the level of access that the application is requesting. This can be a space-separated list of scopes. Not all services require this parameter.

    • Example: scope=api://woepnupr/hl7-services

Here’s an example of a curl command that includes these attributes:

curl --location --request POST 'https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token' \ --header 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode 'grant_type=client_credentials' \ --data-urlencode 'client_id=YOUR_CLIENT_ID' \ --data-urlencode 'client_secret=YOUR_CLIENT_SECRET' \ --data-urlencode 'scope=api://woepnupr/hl7-services/.default'

In this example:

  • Replace {tenant} with your Azure AD tenant ID.

  • Replace YOUR_CLIENT_ID with your actual client ID.

  • Replace YOUR_CLIENT_SECRET with your actual client secret.

These attributes are essential for the client credentials grant flow, which is typically used for server-to-server interactions where no user is involved.

Testing with Postman

If you're having trouble with the curl statement, consider testing out the service in Postman (or equivalent development application). The screenshot below shows how your postman request (POST) should be constructed. Further details, including a demonstration video are available on the SharePoint site