Skip to end of metadata
Go to start of metadata

Overview

Description: This workflow describes how authentication and authorisation of systems making use of the HIE is done through the HIM. This workflow provides the security underpinning for many other workflows that rely on a secure connection and authorised message delivery.

Sponsor:  Ryan Crichton, with the IL (HIM) community

Status:  Completed

Last Modified:  12rd March 2015

Referenced Standards and APIs:

Actors

  • MoH - This actor represents the authority that controls access to the HIE. This is likely a Ministry of Health or a Department of Health.
  • PoS - The Point of Service application that is connecting to the HIE.
  • IL Core - The Interoperability layer core component that provides a single entry point for message destined for systems within the HIE, it provides security, audit and logging capabilities.
  • IL RBAC - The interoperability layer role-based authentication control (RBAC) component.
  • IL Orchestrator - This is a message specific orchestrator that is able to process and orchestrate a particular message based on the messages contents.
  • Some registry - This represents one of the other registry components of the HIE.

 

Technical details

 

 

RefInteractionEndpointDataTransaction Specification
1The PoS application is approved (via the appropriate policy) to be able to communicate with the HIE policy 
2The IL is used to register the application and\n a certificate and key are generated for them details about the application 
3The certificate and key are downloaded from the IL in .pem format 
4The certificate and key are supplied to the PoS admin in .pem formatSneaker-net
5The certificate and key are installed into the PoS application   
6The IL is used to register the application and upload their existing certificate   
7A message is sent over a secure connection using TLS mutual authentication  ATNA Node Authentication
8The client certificate is validated to authenticate the PoS application   
9Checks if the PoS has the authority to send this message on to the required registry   
10Message forwarded   
11Inspects message contents   
12Checks if the application has the required authority   
13Returns true if the application has the correct authority   
14Message forwarded   
15Response returned   
16Response returned   
17Response returned   
18Message forwarded   
19Response returned   
20Response returned