Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Standard updated to v2.0.0 as per Roadmap Item RM188 and Patch changes applied to Summary Care Record DMS 5.8 & Authentication and Access link


Page Properties


 
IDS60
Version12.0.0
TypeInteroperability Standard
StatusEffective
Effective Date
Insert excerpt
Day One Effective DateDay One Effective Date
nopaneltrue
Framework(s)



Table of Contents

Introduction

The Summary Care Record (SCR) is an electronic record of important Patient information, created from GP medical records. It can be seen and used by authorised staff in other areas of the health and care system involved in the Patient's direct care.

From an interoperability perspective there are two aspects to the summary care recordSummary Care Record:

  1. The creation and updating of the summary care recordSummary Care Record
  2. Providing the ability for authorised staff to access the summary care record, for which there are a range of optionsSummary Care Record

Both of these aspects are covered in the documentation below.

Additional information is available at NHS Digital's summary care record site

Compliance, Assurance and Testing

on the Authority's Summary Care Records (SCR) site.

Requirements 


Applicable Suppliers
Requirement ID
Requirement
Level
Suppliers of new services or applications (i.e. those which are NOT currently deployed into an operational environment with existing SCR compliance).SCR01Implement and maintain the API inline with the latest specification version of SCR FHIR API.MUST
SCR02

Implement and maintain the SCR FHIR API inline with the GP Summary Requirements Refactored latest specification version.

View file
nameGP Summary Requirements Refactored for SCR FHIR API.docx
height150


MUST
SCR03

Implement and maintain the SCR FHIR API inline with the GP Summary Presentation Text Specification Refactored latest specification version.

View file
nameGP Summary Presentation Text Specification Refactored for SCR FHIR API.xlsx
height150

MUST
SCR04

Implement and maintain the SCR FHIR API inline with the SCR Viewing Requirements Refactored latest specification version.

View file
nameSCR Viewing Requirements Refactored for SCR FHIR API.docx
height150

MUST
SCR05

Implement and maintain the SCR FHIR API inline with the Technical Specification for GP Summary XHTML latest specification version.

View file
nameSCR FHIR API Technical Specification for the GP Summary XHTML.docx
height150

MUST
SCR06

Implement and maintain the requirements detailed in the COVID-19 SCR Additional Information Requirements latest specification version.

View file
nameCOVID-19 SCR Additional Information requirements.docx
height150

MUST
Suppliers of services which ARE currently deployed into an operational environment, and have existing SCR compliance.SCR07
Implement the requirements detailed in the GP Summary Requirements v5.8.3 or later e.g. SCR FHIR API 

View file
nameGP Summary Requirements v5.8.3.docx
height150

MUST


All suppliers are encouraged to work towards compliance with the latest version as above.

Compliance, Assurance and Testing

SCR FHIR API

For Suppliers of new services or applications, see the Summary Care Record (SCR) section on Onboarding Overview of the Digital Care Services Interoperability Standards and Requirements.

NHS Summary Care Record Service - GP Summary Requirements v5.8.3

For Suppliers of services which ARE currently deployed into an operational environment:

advice


Expand
title Click here to view historical assurance approach

To gain access to SCR suppliers follow the Common Assurance Process (CAP). CAP is an end-to-end assurance process, which involves a tailored (CAP) approach being developed which states what deliverable and activities are conducted.

As part of the CAP suppliers will be asked to demonstrate adherence to the following specifications:

These specifications contain a set of generic requirements applicable to all systems seeking compliance to a business domain. Compliance with these specifications is mandatory and established through the CAP.

For 

For advice, access to the documentation, and support from the NHS Business Partners programme, please contact businesspartners@nhs.net

 or visit  document

.docx document provides guidance on the clinical safety validation processes for SCR messaging.


Documentation

SCR FHIR API

For Suppliers of new services or applications:

It is recommended to read GP software developer guide in conjunction with the API documentation.

NHS Summary Care Record Service - GP Summary Requirements v5.8.3

For Suppliers of services which ARE currently deployed into an operational environment.

Expand
titleClick here to view previous SCR requirements documentation

Summary Care Record Creation

GP Summaries are created and sent to the Summary Care Record repository (on Spine) via messaging from GP systems which implement the Patient Information Maintenance - GP capability.

To create summary care records and provide them to the service, suppliers must implement the requirements detailed in GP Summary Requirements v5.8.3.

Summary care messages contain XHTML information and generated messages must conform to the specification in NPFIT-SHR-MODL-SUMREC-0025 08 GP Summary Presentation Text Specification v3.1 (Approved).xlsx

Implementations must comply with the NPFIT-EP-DB-0007.05 Allergy_ADR_Intolerance v 1.5 Draft

 for

.doc for all representations of medication-related adverse clinical events.

Implementations must comply with the SCR GP Summary Sending Compliance v3 - Baseline Index v6.0

Message definitions are detailed in the Domain Message Specification (DMS) for Summary Care Record  

Further information useful for implementers of this interface such as Use Cases, Trigger Events and Sequence Diagrams may be found in the Spine Message Implementation Manual (MIM).  NB version 4.2 is the version used for the GP Summary Update message.

Also, see MIM 4.2.00 Known Issues.doc

Summary Care Record Viewing

SCR viewing must be implemented in line with the Summary Care Record Permission To View Guidelines.pdf

General requirements for SCR viewing (regardless of implementation mechanism) are set out in NPFIT-FNT-TO-DPM-0929.03 SCR Viewing Requirements v1.6 (Approved).docx

Guidance for implementing Role-Based Access Control for SCR viewing is found in NPFIT-SI-SIGOV-0073 04 Guidance on Implementing RBAC for PSIS and PDS v2.0.doc

Suppliers have a number of options for implementing summary care record viewing, as detailed below:


Option
Description
Documentation
1 clicka simpler and less resource-intensive way to enable SCR viewing into local applications. This solution allows a user of an application to click and launch the SCRa in a separate window for a specific patient.
Spine mini servicesSpine mini services (SMS) are a more lightweight way of developing read-only integration with some national Spine services. SMS Client systems allow SCR access with patient permission and for Emergency Reasons. SCR Viewing systems will be able “plug into” the SCR Spine Mini-Service functionality of the SMS Provider. The SMS Provider system provides various defined functions and services for SCR Viewing systems, e.g. the SMS Provider would retrieve GP Summaries and manage “Permission to View” on behalf of viewing systems (clients).

SCR - Spine Mini Service Provider Requirements-v1.3.docx

SCR - Spine Mini Service Client Requirement04.1.docx

Full SCR integration

Integration of SCR information into the GP clinical system. 

A GP system retrieves GP Summaries from the Summary Care Record on Spine using the PSIS Query message and displays it via appropriate screens within the GP clinical system.

SCR_Viewing_Requirements_v3.0_(Approved).docx

Summary Care Record DMS 5.8
 

.doc (sections relevant to PSIS Query)

MIM 7

.
.


Dependencies

Creating

Excerpt

Summary Care Record FHIR API

For Suppliers of new services or applications:

NHS Summary Care Record Service - GP Summary Requirements v5.8.3

For Suppliers of services which ARE currently deployed into an operational environment:


Expand
title Creating a compliant implementation requires implementing the following dependent interface standards

:excerpt


Roadmap

Page Properties Report
headingsStandards and Capabilities, Status, Effective Date, Description, Change Type, Change Route
pageSize300
sortByEffective Date
cqllabel = "S60" and space = in ( currentSpace ( ) , "DCSDR" , "DCSDCS" )