Search loading...

API Hub

Explore and Make use of Nationally Defined Messaging APIs

 

SMSP Target Operating Model

SMSP Target Operating Model

SMSP Target Operating Model

The purpose of the Target Operating Model (TOM) is to inform and assist deploying organisation with the implementation of SMSP integrated systems within their local environment. In particular, it provides an assessment framework of their responsibilities in terms of ensuring that their local systems meets the technical, IG, Clinical safety, and functionality required for the business context.

The TOM is currently presented in a form of a spreadsheet, with the worksheet broken into the logical assessment sections.

The TOM is typically used in two phases: - Phase 1 the usage and settings information provided to NHS Digital for approval. - Phase 2 the actual assessment phase conducted by the supplier and the deploying organisation.

Note: once a complete assessment has been performed by a deploying Organisation and supplier, the TOM will typically remain largely unchanged (in terms of the risks/mitigations identified) for subsequent deployments, hence new deployments will simply require the new organisations details and any local context changes to the assessment.

Details of the sections within a Target Operating Model

Profile

The tabs represent the sections contained within the TOM. A brief description is provided.

Approval

[Completed typically by the project manager or individual responsible for the new deployment]

There are two phases.
Phase 1 - details the individual who will assess the Usage and Settings information provided within this Target Operating Model. This phase can also be used for developer organsation to valid potential use cases.
Phase 2 - This section details the individual who has final approval for this Target Operating Model evaluation.

<

Details

[Completed typically by the project manager or individual responsible for the new deployment]

This section captures basic information about the Spine Mini Service being assessed.

Deployment Topology

[Completed typically by the technical lead responsible for the new deployment]

Shows the NHS Digital recognised topologies. One must be select as part of the evaluation process.

Contacts

[Completed typically by the project manager or individual responsible for the new deployment]

This section provides a reference list of stakeholders who MAY need to be contacted, as an aid to building a virtual project team. It allows specific contact details to be recorded for those roles which are relevant - both for day-to-day practical purposes, and as an audit trail of those involved.

Contracts

[Completed typically by the project manager or individual responsible for the new deployment, with assistance from technical lead]

This section captures information about the Organisation using the data and the associated legal agreements. Also Supplier agreement with NHS Digital.

Accountability

[Completed typically by the project manager or individual responsible for the new deployment]

This section examines the respective responsibilities of suppliers and Deploying Health or Social Care Organisations. It provides best-practice guidance which Deploying Health or Social Care Organisations must consider when assuring the end to end connection. It defines areas that each party must action or consider.

Architecture

[Completed typically by the technical lead responsible for the new deployment]

This section examines the system architecture to ensure that it is fit for purpose. It provides best-practice guidance which Deploying Health or Social Care Organisations must consider when assuring their own architectures. The intention is for the spreadsheet to act as a checklist and cross-reference to ensure that all necessary points are covered in more detailed technical documentation.

Information Governance

[Completed typically by the technical lead responsible for the client solution]

This section confirms the Information Governance (IG) controls required, and the mechanisms for implementation of each. The emphasis is on highlighting the business requirement for a particular IG control, rather than mandating that a particular technical mechanism be used.
For each IG control a number of recognised technical implementation mechanisms are listed, and use of these pre-established mechanisms can accelerate implementation.
Where a non-standard technical implementation mechanism is proposed then the checklist will highlight the need for further review and risk assessment by the Deploying Health or Social Care Organisation's Senior Information Risk Owner (SIRO).
Brief guidance on each topic is provided as part of the checklist, however extensive further information can be found in the "IG Guidance" documentation of the ITK Trust Operating Model (TRUD)
The IG checklist applies to all components within the solutin. It should be noted there exists additional client specific IG requirements detailed in the 'SMS Generic Client Reqs' tab.

Clinical Safety

[Completed typically by the clinical safety officer responsible for the new deployment]

This section confirms actions required to mitigate Clinical Safety risks.
If further guidance is needed then the NHS Digital Clinical Safety Group may be contacted at clinical.safety@nhs.net

SMS Generic Client Requirements

[Completed typically by the technical lead responsible for the client solution]

This section assesses the application against the published set of Trust Operating Model Spine Mini Service Client Requirements.
These requirements effectively form the Foundation Requirements capabilities.

SMS Demographics Requirements

[Completed typically by the technical lead responsible for the client solution]

This section assesses the application against the published set of Trust Operating Model Spine Mini Service Client Requirements.
These requirements effectively form the demographics Demographics Requirements capabilities


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