White Paper: Authentication and authorisation for FHIR interfaces onto local and national services/systems
A common ask from healthcare software suppliers, especially those in the patient-facing application market, is how will applications authenticate and be authorised to access data held in national services or systems, such as Spine Demographics or the Electronic Prescription Service (EPS), and local clinical systems such as those used in General Practice or Community/Social Care.
Today, the only systems that can use the full functionality of national services like Spine Demographics or the EPS are clinician-facing systems such as those used in General Practice, hospitals or community pharmacy. Access control is via two-factor authentication using NHS smartcards, with authorisation via the national RBAC ‘activities’. Patient-facing systems have limited access to data. They can access some national directories like the Directory of Services (DoS) or Organisation Data Services (ODS) and to GP systems but via the legacy and bespoke IM1 Interfaces that will be replaced by GPConnect. Some of these services are only available via the Health and Social Care Network (HSCN).
To encourage innovation within the healthcare IT sector, to provide clinicians and patients with more complete, accurate, timely and appropriate access to data, we need to provide more ‘open’ software interfaces. These need to be available over the Internet, not behind the walls of the HSCN, but of course be secure, robust and achievable (in terms of time and money).
This white paper outlines the authors vision for how a technical architecture would support authentication and authorisation. As of September 2018, the following services are theoretical, and therefore may not be implemented, or in the early stages of implementation;
- NHS Identity
- Citizen Identity
- API Management Layer.
The human end user has a proven identity. If an NHS user, then a proven identity within the NHS Identity service. If a patient, or patient’s representative, a proven identity within the Citizen Identity service.
The clinical application being used initiates the user authentication process with a RESTful request to the NHS/Citizen Identity service. The response, if valid, includes a JSON Web Token which will be used within API calls to other services. See https://developer.nhs.uk/apis/spine-core/security_jwt.html.
The authentication service may also return authorisation data for the user, or this may be returned via a separate request. Either way, the user’s authorisation will be defined within a “scope” returned within a JSON Web Token. See https://developer.nhs.uk/apis/spine-core/security_scopes.html.
Scopes can map to the national RBAC ‘activities’ to replace the current use of SAML responses from the NHS smartcard authentication process. Systems that have implemented local RBAC can continue using that but should migrate to using scopes when FHIR interfaces are used to access secure data. It is acknowledged that parallel running of RBAC and Scopes for authorisation will be complex.
The application now has an authenticated user and as the authorisation “scope” for what data the user is permitted to access or update within national or local NHS systems.
Requests to local or national services via a FHIR interface must then include the JSON Web Token in the HTTP authorisation header as an oAuth Bearer Token. The API Management Layer within the Digital Interoperability Platform will act as the entry point for all FHIR API’s, enforcing authentication and authorisation controls. This also provides the opportunity for orchestration requests, e.g. combining data from different services into a single response. An example would be where both demographic and clinical data is required, simplifying the client/consumer via a single request rather than multiple requests. One likely strategic objective for orchestration would be to return “current medication”, which may combine data from multiple sources (e.g. GP, hospital, urgent and emergency care), using the National Record Locator Service (NRLS) for sign-posting, with rules and logic to include/exclude results, including de-duplication.
The API Management Layer would sit in front of services like the Spine Security Proxy that simplifies connectivity to the clinical systems that have implemented a common FHIR interface. Today that is just the first release of GPConnect FHIR interface implemented by the General Practice clinical systems. In the future that could include CareConnect FHIR interfaces to access clinical systems in other care settings such as urgent and emergency care, community pharmacy or care homes.
Legacy API’s into local and national systems will still be available during any transition period. National services like Demographics and the Electronic Prescription Service will retain their ebXML/HL7v3 interfaces using locally implemented RBAC for authorisation. In the future they may implement a parallel FHIR interface giving appropriate secure access not only to NHS facing systems but also patient facing systems. The API Management Layer could also provide a backwards compatibility service between a legacy service using an HL7v3 interface and a new client/consumer using a FHIR interface. For example; A client/consumer requesting patient demographics via a RESTful FHIR request. The API Management Layer transforming the FHIR request into an ebXML/HL7v3 request, handling the response and transforming the response into a FHIR payload.
This end-to-end model from end-user authentication through to secure access to appropriate personal or sensitive data is the enabler for innovation within the NHS. Clinical systems used by NHS organisations can have access to records held anywhere across the NHS using consistent and secure access methods. Patient-facing applications will give the patient’s secure and appropriate access to their NHS data wherever it is held. It will allow patients and their representatives to take control over their NHS services, reducing the administrative burden on NHS organisations.
About the Authors
Rob Gooch, Adam Hatherley and Simon Gordon are Senior Technical Architects working for NHS Digital and are the respective technical leads for Digital Medicines, Interoperability and Identity/Authentication.
Was this article useful?3