Search loading...

API Hub

Explore and Make use of Nationally Defined Messaging APIs

 

Foundations Requirements

Information Governance – Organisational

Ref Description
MSCA-ORG-01 The deploying organisation MUST conform with the Acceptable Use Policy for Spine Mini Services
Note 1 Spine Mini Services may be used by NHS Organisations, for the purposes of provision of care.
Any other uses will be considered on a case by case basis - they MUST be proposed and agreed in writing by HSCIC.
Ref Description
MSCA-ORG-02 The deploying organisation MUST put in place back-office data quality processes to handle any discrepancies which the use of Spine Mini Services reveal
Note 1 Spine Mini Services provide access to National Systems. This is likely to lead to discrepancies being discovered with local records. Back office data qualityprocesses MUST be put in place to handle this, including:
  • Process for front-line staff to notify back-office of a potential discrepancy
  • Back-office investigation process to decide what to do
  • Back-office process to request an update to National Systems where necessary
Ref Description
MSCA-ORG-03 The deploying organisation MUST consider the impact of rolling out Spine Mini Services on staff and job roles
Note 1 Typically the use of Spine Mini Services will increase the role of front-line staff in confirming that demographic details are entered correctly at the point of capture.
Whilst this has many advantages, it is essential that any implications of this additional activity are considered, and any necessary training is provided.
Piloting and a phased rollout would typically be used as part of this approach.

Information Governance – General

Ref Description
MSCA-IG-01 The Mini Services Client Application MUST provide RBAC control over access to its features
Note 1 The Mini Services Client Application MUST protect is functionality with RBAC controls sufficient to meet IG Requirements for a system accessing Spine data. This includes:
  • Implementing role-based access control to authorise users’ access to the system’s functions and data.
  • Restricting access to view audit trails
  • Protecting RBAC configuration data

    • Note that the use of local RBAC is acceptable
Ref Description
MSCA-IG-02 The Mini Services Client Application MUST provide authentication control over access to its administration and other features
Note 1 Authentication MUST be based on a user identity which is then authenticated at least through the use of a separate password.
  • The use of two-factor authentication mechanisms (eg Smartcard) is encouraged but not mandated
  • Where passwords are used then password management processes and policy enforcement are essential. The guidance documentation referenced in the Trust Operating Model (“Password Policy for Non-Spine Connected Applications”) therefore applies.
Ref Description
MSCA-IG-03 The Mini Services Client Application MUST display basic security context information to the user
Note 1 This includes:
  • Computer misuse warning on start-up
  • Confirmation of the logged on user’s current role and organisation
Ref Description
MSCA-IG-04 The Mini Services Client Application SHOULD ensure appropriate labelling of personal data
Note 1 This includes protective labelling of personal data both on-screen and in printed output.
Ref Description
MSCA-IG-05 The Mini Services Client Application MUST be hosted in a managed and secure environment
Note 1 The capability and responsibility of the deploying organisation, and acknowledgement of the risk ownership, is to be demonstrated through the maintenance of an approved IG Statement of Compliance (IGSoC1)

Audit

Ref Description
MSCA-AUD-01 The Mini Services Client Application MUST provide a secure audit trail
Note 1 This includes:
  • The Mini Services Client Application MUST provide a secure, tamper-proof audit store sufficient to meet IG Requirements for a system accessing National Systems data.
  • This includes protecting the audit store from deletion or modification, and ensuring that audit trails are enabled at all times.
  • Audit data MUST be stored for periods as defined by DH policy and described in the NHS Records Management Code of Practice Parts 1 and 2.
  • (see https://www.gov.uk/government/publications/records-management-nhs-code-of-practice )
Ref Description
MSCA-AUD-02 Events that MUST be audited
Note 1 The Mini Services Client Application MUST audit all relevant events, sufficient to meet IG Requirements for a system accessing National Systems data. This includes:
  • All information exchanges with NHS CRS, including messages sent and received via Spine Mini Services
  • Changes to reference and configuration data
  • Successful login, unsuccessful login attempts and logouts, password changes
Ref Description
MSCA-AUD-03 Data Items that MUST be audited
Note 1 The Mini Services Client Application MUST capture relevant data items in the audit store sufficient to meet IG Requirements for a system accessing National Systems data. This includes:
  • User Identity (see MSCA-AUD-04 below for more about what this must contain)
  • Timestamp (synchronised from the national time service)
  • Audit event details
  • Identity of associated data (e.g. patient’s NHS Number)
  • A sequence number to help protect against tampering
  • The originating system identifier
  • Message ID of any messages sent to the Mini Services interface
Ref Description
MSCA-AUD-04 The Mini Services Client Application MUST provide an Audit Identifier for the initiating user when calling Spine Mini Services
Note 1 The ITK Distribution Envelope provides an “Audit Identifier” field for the purpose of allowing the client application to pass an identity for the end user initiating the Mini Services request.
  • This Audit Identifier field MUST be populated by the Mini Services Client Application.
  • It MUST contain an ITK format of Audit Identity (see example below)
  • Additionally if an SMSP client system is smartcard enabled then the User Role Profile and User ID MUST both be supplied, and the Role ID MAY be supplied
  • If the Mini Services Client Application is not smartcard enabled then an alternative local unique identifier for the user MUST be presented in the Audit Identifier field.
Note 2 An SMSP itk audit identity may look like this.
type="1.2.826.0.1285.0.2.0.107" uri="868000003114"
Where the uri value is the accredited system id (asid)of the connected cunsumer system.
Ref Description
MSCA-AUD-05 Audit entries MUST be available on a queryable interface
Note 1 The Mini Services Client Application MUST provide an interface for interrogating the audit log sufficient to meet IG Requirements for a system accessing National Systems data.
Searchable parameters MUST include user identifier, Message ID, Patient ID, date/time.
Ref Description
MSCA-AUD-06 The Mini Services Client Application MUST utilise a Stratum 3 time source as a minimum
Note 1 The Mini Services Client Application MUST utilise a Stratum 3 time source as a minimum however implementers SHOULD consider the use of Stratum 2 or above.
This enables meaningful comparison and sorting of messages based on timestamps. It is particularly important to enable an end-to-end trace of events to be established all the way from the Mini Services Client Application, through the SMSP.
Ref Description
MSCA-AUD-07 Audit timestamps generated by Mini Services Client Application MUST comply with issued guidance on time zones

All content is available under the Open Government Licence v3.0, except where otherwise stated