Authentication

This section outlines:

  • Access controls in place for use of the service
  • Process for obtaining access tokens (for both providers and consumers)
  • Provisions for auditing use of the service
  • Security procedures in place
  • How this service is integrated into SPINE authentication services

Access control

In Genomics, users may need to request or contribute to genomic testing while acting in multiple roles, e.g. by specialty/organization. Granular controls for restricting users to specific test types or test requests have been found to be difficult to implement. Local providers have thus opted to use broad access controls to separate users who are involved in genomics testing and those who are not.

Requirements elicitation has found that constraining access to test requests by organization, where the user is logged in, is a reasonable approach. Where there are users who work at multiple organisations, they should only see test requests and tasks for the organisation they are logged in to.

Further access controls could be implemented if a requirement arises to restrict things further, by adding additional claims to the access token passed in by the requesting system.

Access control is expected to match controls in place for existing national services, users will be expected to authenticate via the national care identity service (CIS2).

Suppliers will be expected to onboard onto the service through NHS England's API onboarding service.

Portal Authentication

CIS2 is the preferred authentication mechanism for national services and enables a number of different mechanisms to authenticate in a secure manner. More details about the service can be found on the NHS England Care Identity Authentication pages

Users can currently authenticate using any of the following five options:

  • Windows Hello for Business
  • Security Keys
  • iPad App
  • Microsoft Authenticator
  • Smartcards

The expected users of the national portal may be technically immature organisations and will only require infrequent access to the service, but the expectation is that they will be able to use one of the authentication mechanisms available within CIS2.

Note: For each of the authentication mechanisms, there is restrictions about device versions, setup and access controls which needs to be taken into consideration when onboarding services, details can be found on the CIS2 guidance for Registration Authorities

API Authentication/Authorization

The API will support two types of authentication for systems directly integrated with the service:

  1. Where a user is present the user should be authenticated using CIS2 and the token should be passed through with the request, as is specified for the portal requirement above.
  2. Where the request is being made in an unattended scenario, such as a system polling to see if new tasks have been created for them, the API will support application level authentication.

The API-M layer will manage general access to the API for both user and application level authentication, but the signed token for both types of authentication will be passed through to the service, where we can apply additional authorization based on claims within the token if we need to. This is the same model used by services such as NRL FHIR R4 APIs.

User Authentication

CIS2 is the preferred user authentication mechanism for accessing national services, both from an authentication perspective as well as an audit perspective.

The user’s authentication token will need to be sent with the request to the API and will contain claims which represent their access permissions.

The Genomic Medicine Service will expect clients to follow the National RBAC guidance for developers when registering and authorising users.

Application Authentication

For unattended API calls, application level authentication using APIGEE OAuth2.0 capability within API-M will be used. This mechanism is currently being used for other national services such as NRL FHIR R4. Information for integration with this service is available on the NHS England developer guidance pages

The connecting system will need to get a signed token and pass it to the genomics test order API with their request. The token will be passed from the API-M layer back to the Genomics services where the service will use the claims in the token to apply appropriate access controls. For the alpha the access controls within API-M which control access to the API as a whole will be sufficient to meet the requirements, but the service will need to process the token for audit purposes and possibly additional access controls in beta and further development phases.

Purpose-Based Access Control

Within the Unified Genomic Record, there is a need to restrict access to particular aspects of a patient's genetic profile, or family linkage, based on a user's role, the purpose for which they are accessing the data, the activities they are performing (e.g. CRUD operations) and the patient's own consent.

This work is currently in discovery to elicit concrete requirements of how these access controls need to be represented, as well as how the claims themselves are represented and tested before providing access to a UGR record.

It is expected the framework will align to IHE PCF, with consent representing the patient's own directives and security tags representing an overall level of sensitivity of classes of information.

The particular representation of claims is pending investigation but it is expected these will align somewhat to OpenID Connect or OAuth2. At the present time, there is no NHS England service which is able to support Attribute-Based Access Control (required to represent activities/purposes being performed by the user).

The level of granularity the consent and PBAC policies will need to support, e.g. Classes of resources, specific instances or specific attributes within those instances, is also pending investigation.

Auditing

Audits will align to NHS England internal standards for national services.

  • Logs will contain all interactions that occur on service.
  • Logs will be designed and implemented to prevent editing or deleting of data by users.
  • Logs will contain detail on processes within the service to support investigation into errors and issues.
  • Logs will in the long run be connected to the NHS England Splunk logging process, but for the alpha will only be internal to the service as other services have proved the integration of cloud services with NHS England Splunk logging..
  • The service will aim to minimise the storage of duplicate data, to reduce costs for running the service.
  • Logging will be separated into PID data which needs to be retained under the retention policy and system logs which can be archived or removed sooner than the PID logs.

The mechanism for auditing test orders and responses is subject to the architecture chosen for the Genomic Medicine Service. It is expected that all messages submitted to the system, as well as access to records on the system, will be logged via AuditEvent resources to ensure all accesses and updates are auditable.

Updates to controlled documents, such as ServiceRequests and DiagnosticReports will further be accompanied by Provenance resources, submitted by clients, to capture who made a change and why.

Security

This page describes the security guidance/requirements.

Security of data and the service will be done to conform to the security standard expected for any NHS England service:

  • Encryption at rest and in transit
  • Appropriate levels of authentication of users
  • Appropriate RBAC controls, utilising strategy of least privilege
  • Maintenance plan for software and library versions and any ad-hoc security patches
  • Audit of access to both front and back-end services

It is expected only active healthcare professionals, within particular specialties, will be able to order Genetic tests and only recipient GLHs/labs or requesting clinicians will be able to view tasks related to a test order.

Finally, it is expected only clinicians responsible for interpretation of a genetic test, or the clinician responsible for care of the patient will be able to access the Diagnostic Report produced, subject to standard break-glass procedures.

Integration with central services

Any information which can be retrieved through use of an existing national service is not expected to be duplicated in messages within the Genomic Medicine Service. Instead, these resources should be referenced, following the Bundle referencing guidance.

These services include but are not limited to:

  • ODS for organisation search
  • SDS for practitioner details
  • NRL for resource location
  • PDS for patient demographics (A patient resource will still be expected to support consistent querying across patients both registered and not registered with PDS)
  • NHS App for patient empowerment

How providers/consumers should integrate with central services is pending a finalised architecture for the Genomic Medicine Service.

Temporary Registration/ Merge Patients

The core identifier for a patient is the NHS number. If a patient does not have an NHS number a local ID is allocated to identify the patient. In the event there is a duplication of records of the same patient, the activity of merging/de-merging of records should occur in the source (EPR) systems and inform PDS. Any communication to the core infrastructure should utilise an NHS number. In the event, an NHS number is not available, temporary identifiers (local IDs) may be used. All organisations involved in utilising the genomics service SHALL be PDS compliant.

The core infrastructure SHALL have the capability to manage merge scenarios in a transparent and auditable manner for the end users. Any superseded tests allocated to a record will be merged into the parent patient record as informed by PDS.

Where there is no PDS integration, automatic merging of patients within the core infrastructure will not be possible. There may be a potential for duplicate records which will need to be managed through the core source system used within the organisation.

The expectation is that patients who do not have an NHS number will have a test request created based on a local identifier (Hospital ID or local ID provided by the originating organisation) to progress the genomics test request and bypass the need to temporarily register the patient.

In the event there is a duplication of records (same patient), the activity of merging/ de-merging of records should also occur in the local EPR and/or LIMS. Local policies should be followed in the event of merging/de-merging a parent and duplicate record. The subsequent master record (post merge) should display the merged record in downstream systems.

Sensitive/Restricted Patient Records

At times, PDS may mark patient records as sensitive, redacting information from responses which may be used to locate a patient. As demographic information is not expected to be duplicated within the central service, for patients registered with PDS, this should not impact the data stored on the central service. In this case, the demographics as well as the sensitive flag for the patient, should be retrieved directly from PDS.

Where patients are not registered with PDS, it is expected source systems will redact the necessary information (e.g. address, telecom, related persons, GP practice, pharmacy etc.) from the messages sent to the central broker in order to be GDPR/PDS compliant.

While every effort will be made to honour the sensitive nature of patient records, where binary data is uploaded to the central server, as in the case of unstructured reports, this information cannot be redacted by the central service. It is the responsibility of source systems to redact the necessary information from binary files before sending this data to the central broker.

Data Enrichment and Maintenance

The service will have a road map item to explore and integrate with services such as PDS, NEMS and ODS APIs to check data quality.

For creation and update of service requests this should not be necessary as there is an expectation that systems connecting to the test order service will have recently verified these details against the same national services, but there will be scenarios such as superseded NHS numbers and deceased patients which will not be captured if a supplier does not interact with the service when this happens, therefore the service would need to be notified or poll PDS to check for updated NHS numbers or changes to deceased status.

RelatedPerson and familial relationships/linkage

The PDS service currently supports the RelatedPerson resource. Use of this resource is currently limited to representation of carers, next of kin, or other individuals serving as contact points for the patient, with expectations this will extend to proxy relationships in the future.

While Genomics also uses RelatedPerson, the use case is quite different. Within Genomics, there is the need to represent Biological relationships between individuals to support creation of genetic pedigrees, interpretation/evaluation of inheritance of disease and identifying related family members eligible for cascade testing.

These biological relationships are currently solely represented within genomic services (e.g. GOMS, UGR) as PDS is limited to relationships in a legal/administrative context. There are a number of concerns regarding representation of biological relationships within a demographics service, e.g. natural father not being the same as the father figure raising a child, which could lead to information governance/legal issues. As such, biological relationships will remain within the purview of genomic services for the forseeable future.

Proposed Architecture

architecture

Architectural decisions as well as the low level design for the service can be found on the Genomic Order Management NHS Futures pages