ID | STD006 |
|---|---|
External ID | N/A |
Version | 1.0 |
Link to standard | ISB1523: Anonymisation Standard for Publishing Health and Social Care Data |
Standard Type | Data Standard (NHS) |
Status | Alpha |
Effective Date | TBC |
Description
This process standard provides an agreed and standardised approach, grounded in the law, enabling organisations to: distinguish between identifying and non-identifying information, and deploy a standard approach and a set of standard tools to anonymise information to ensure that, as far as it is reasonably practicable to do so, information published does not identify individuals.
Applicability
The following persons or bodies must comply with this process standard:
a. The Secretary of State (DH)
b. The NHS Commissioning Board (once established)
c. any public body which seeks to publish information relating to the provision of health services or of adult social care in England;
d. any person commissioned (by a public body) to provide such health services or adult social care who seeks to publish information relating to them;
e. any person registered as described in s20A of the Health & Social Care Act 2008.
Requirements
Requirement ID | Requirement Text | Level |
|---|---|---|
STD006-1 (Section 2.1) | All Health and Social Care bodies choosing or obliged by law to publish (electronically or on paper) information/data relating to, or derived from, personal identifiable records MUST anonymise information so that information published does not identify individuals. | MUST |
STD006-1 | Health and Social Care bodies choosing or obliged by law to publish information/data relating to, or derived from, personal identifiable records MUST have regard to this process standard. | MUST |
STD006-2 | 2 When publishing information after 1 April 2013, affected organisations MUST either: a) follow this standard; or b) follow alternative guidance of a similar standing. | MUST |
STD06-3 | 3 If alternative guidance of a similar standing is used, affected organisations MUST record their reasons for choosing the alternative, and make their reasons available on request. | MUST |
STD006-4 | 4 Whether this standard or alternative guidance is used, affected organisations MUST conduct, record, and make subsequently available on request, a risk assessment regarding the possibility that specific individuals might be identified from the published material either directly or indirectly through association of the published material with other information/data in or likely to be placed in the public domain. | MUST |
STD006-5 | 5 Whether this standard or alternative guidance is used, affected organisations MUST record, carry out, and make subsequently available on request, an anonymisation plan, and SHOULD record their reasoning for choosing that plan. A spreadsheet for this purpose is provided and Anonymisation Standard for Publishing Health and Social Care Data Specification 21/02/2013 Final v1.0 © Crown Copyright 2013 Page 15 of 41 MAY be used. | MUST/SHOULD |
STD006-6 | 6 Whether this standard or alternative guidance is used, affected organisations MUST, prior to publishing, confirm with the organisation's Caldicott Guardian or other responsible officer that the information to be published does not identify individuals, and this confirmation MUST be recorded and be available subsequently on request. | MUST |
STD006-7 | 7 Where data previously published by the affected organisation are found to have led to confidential information about an individual being revealed, organisations SHOULD carry out an investigation into the incident and review their procedures for anonymising and publishing health and social care data. Any concerns, or suggested improvements, relating to this standard SHOULD be notified to the Health and Social Care Information Centre at: enquiries@ic.nhs.uk. | SHOULD |
STD006-8 | 8 Organisations using the standard may wish to conduct a periodic audit to check the process is being followed and that appropriate judgements are being made by staff using the standard.. | SHOULD |
ID | STD016 |
|---|---|
External ID | N/A |
Version | 1.0 |
Link to standard | |
Standard Type | Data Standard (NHS) |
Status | Alpha |
Effective Date | TBC |
Description
This standard provides a set of requirements suitably structured to promote and ensure the effective application of clinical risk management by those health organisations that are responsible for the deployment, use, maintenance or decommissioning of Health IT Systems within the health and care environment.
The standard includes implementation guidance and is supported by the related standard for the application of clinical risk management in the manufacture of Health IT Systems - DCB0129 (STD017)
Applicability
This standard is addressed to Manufacturer personnel who are responsible for ensuring clinical safety in the development and modification of Health IT Systems through the application of clinical risk management. This standard applies to all Health IT Systems including those that are also controlled by medical device regulations , though the requirements defined in this standard are broadly consistent with the requirements of ISO 14971.
Requirements
Requirement ID | Requirement Text | Level |
|---|---|---|
STD016-1 | Organisations / Suppliers of IT systems that deploy and modify IT Systems used in a healthcare setting MUST ensure that effective clinical risk management is carried out. Within this standard the term ‘clinical risk’ is used to emphasise that the scope is limited to the management of risks related to patient safety as distinct from other types of risk such as financial. | MUST |
ID | STD017 |
|---|---|
External ID | N/A |
Version | 1.0 |
Link to standard | |
Standard Type | Data Standard (NHS) |
Status | Alpha |
Effective Date | TBC |
Description
This standard provides a set of requirements suitably structured to promote and ensure the effective application of clinical risk management by those organisations that are responsible for the development and maintenance of Health IT Systems for use within the health and care environment.
The standard includes implementation guidance and is supported by the related standard for the application of clinical risk management in the deployment and use of Health IT Systems - DCB0160.(STD016)
Applicability
This standard is addressed to Manufacturer personnel who are responsible for ensuring clinical safety in the development and modification of Health IT Systems through the application of clinical risk management. This standard applies to all Health IT Systems including those that are also controlled by medical device regulations , though the requirements defined in this standard are broadly consistent with the requirements of ISO 14971.
Requirements
Requirement ID | Requirement Text | Level |
|---|---|---|
STD017-1 | The suppliers of IT Systems used in a healthcare setting MUST ensure that effective clinical risk management is carried out. | MUST |
ID | STD050 |
|---|---|
External ID | N/A |
Version | 1.0 |
Link to standard | |
Standard Type | Guidance |
Status | Alpha |
Effective Date | TBC |
Description
ISO8000-1 is the global standards for data quality and enterprise master data. It provides assurance that data management and architecture controls are the highest standard
Applicability
Requirements
Requirement ID | Requirement Text | Level |
|---|---|---|
STD050-1 | The supplier of IT Systems used in a healthcare setting SHOULD comply with the principles set out in ISO8000-1:2022 | SHOULD |
ID | STD051 |
|---|---|
External ID | N/A |
Version | 1.0 |
Link to standard | |
Standard Type | Data Standard (External) |
Status | Alpha |
Effective Date | TBC |
Description
ISO9000-1 sets out the criteria for a quality management system and is a standard that can be complied with.
Applicability
The standards provide guidance and tools for companies and organisations which want to ensure that their products and services consistently meet customers’ requirements, and that quality is consistently improved.
Requirements
Requirement ID | Requirement Text | Level |
|---|---|---|
STD051-1 | Healthcare provides SHOULD comply with the principles set out in ISO9000-1 | SHOULD |
ID | STD077 |
|---|---|
External ID | N/A |
Version | 1.0 |
Link to standard | |
Standard Type | Guidance |
Status | Alpha |
Effective Date | TBC |
Description
The Government Service Standard helps teams to create and run great public services.
Applicability
Providers of digital services within the UK government sector
Requirements
Requirement ID | Requirement Text | Level |
|---|---|---|
STD077-1 | IT system suppliers/Providers of digital services SHOULD adhere to the principles below:
Full details can be found here | SHOULD |
ID | STD082 |
|---|---|
External ID | N/A |
Version | 1.0 |
Link to standard | |
Standard Type | Guidance |
Status | Alpha |
Effective Date | TBC |
Description
The Standard of Good Practice for Information Security 2020 (SOGP 2020) provides a business-orientated focus on current and emerging information security issues and helps organisations develop an effective framework for information security policies, standards and procedures.
This latest edition of the SOGP includes new or enhanced coverage of the following Categories, Areas and Topics: Security Workforce, Core Cloud Security Controls, Security Operation Centres, Mobile Application Management, Asset Registers, Security Assurance, Supply Chain Management and Security Event Management.
Applicability
The standards provide guidance and tools for companies and organisations which want to ensure that their products and services consistently meet customers’ requirements, and that quality is consistently improved.
Requirements
Requirement ID | Requirement Text | Level |
|---|---|---|
STD082-1 | Healthcare providers SHOULD comply with the guidance set out in the Standard of Good Practice for Information Security 2020 (SOGP 2020) | SHOULD |
ID | STD092 |
|---|---|
External ID | N/A |
Version | 1.0 |
Link to standard | |
Standard Type | Data Standard (External) |
Status | Alpha |
Effective Date | TBC |
Description
OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. This specification and its extensions are being developed within the IETF OAuth Working Group.
Authentication and authorisation are done together. Authentication is done by NHS CIS2 Care Identity Authentication API but we co-ordinate that under the covers behind our OAuth2.0 authorisation server.
Applications only needs to be registered with the API Platform, not NHS CIS2.
The healthcare worker authenticates with either an NHS smartcard or a more modern alternative. To use smartcards, you need to be connected to the Health and Social Care Network (HSCN).
Applicability
accessing a user-restricted RESTful API
the end user is a healthcare worker
you want a simpler integration
you do not need the healthcare worker's identity information
Requirements
Requirement ID | Requirement Text | Level |
|---|---|---|
STD092-1 | Software suppliers who wish to access user-restricted RESTful API. In particular, the NHS Care Identity Service 2 (NHS CIS2) combined authentication and authorisation pattern, which uses our OAuth 2.0 authorisation server.  | MUST |
ID | STD093 |
|---|---|
External ID | N/A |
Version | 1.0 |
Link to standard | |
Standard Type | Data Standard (External) |
Status | Alpha |
Effective Date | TBC |
Description
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
Applicability
OpenID Connect allows clients of all types, including Web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and end-users. The specification suite is extensible, allowing participants to use optional features such as encryption of identity data, discovery of OpenID Providers, and logout, when it makes sense for them.
Requirements
Requirement ID | Requirement Text | Level |
|---|---|---|
STD093-1 | Authorization Code Flow The diagram below depicts the Authorization Code Flow at a high level:  | SHOULD |
ID | STD096 |
|---|---|
External ID | N/A |
Version | 1.0 |
Link to standard | |
Standard Type | Data Standard (External) |
Status | Alpha |
Effective Date | TBC |
Description
A medical device is a product, such as an instrument, machine, implant or in vitro reagent, that is intended for use in the diagnosis, prevention and treatment of diseases or other medical conditions.
Applicability
ISO 13485 is designed to be used by organizations involved in the design, production, installation and servicing of medical devices and related services. It can also be used by internal and external parties, such as certification bodies, to help them with their auditing processes.
Requirements
Requirement ID | Requirement Text | Level |
|---|---|---|
STD096-1 | Suppliers should have Certification to ISO 13485 Read more about certification to ISO’s management system standards. | SHOULD |
ID | STD101 |
|---|---|
External ID | N/A |
Version | 1.0 |
Link to standard | |
Standard Type | Data Standard (External) |
Status | Alpha |
Effective Date | T |
Description
UPRNs are the unique identifiers for every addressable location in Great Britain
USRNs are the unique identifiers for every street in Great Britain
Applicability
Systems, services and applications that store or publish data sets containing property and street information must use the UPRN and USRN identifiers.
Requirements
Requirement ID | Requirement Text | Level |
|---|---|---|
STD101-1 | IT Suppliers systems, services and applications that store or publish data sets containing property and street information must use the UPRN and USRN identifiers. | MUST |
ID | STD102 |
|---|---|
External ID | N/A |
Version | 1.0 |
Link to standard | |
Standard Type | Data Standard (Internal) |
Status | Alpha |
Effective Date | T |
Description
The purpose of Medicine and Allergy/Intolerance Data Transfer to ensure that medication and allergy information is transferred between systems and locations in a machine-readable format. This will be achieved by:
transferring medication information using the newest UK version of FHIR (Fast Healthcare Interoperability Resource), using either ‘Medication Codable Concept’ or ‘Medication Resource’ as is most appropriate to the use case
usage of dose syntax to transfer the amount of medication per dose as a simple coded quantity
transferring allergy/intolerance information using SNOMED CT and dm+d codes.
Applicability
All NHS care locations that:
need to know a patient’s current medicines and
allergies/intoleranceprescribe, dispense or administer medicines
use computer systems that could send or receive this
information
Requirements
Requirement ID | Requirement Text | Level |
|---|---|---|
STD102-1 | Users, specifically those in charge of their organisation’s IT (Information Technology) systems, must assess their IT systems to identify any electronic transfers of medication and allergy/intolerance to or from other systems, and if any are found determine whether they comply with this Standard, against which compliance is needed by 31 March 2023. | MUST |
STD102-2 | Where non-compliant message transfers are identified, users must make use of contracts they have signed with their IT system suppliers to develop new or update existing products to provide compliance. Alternatively, users might decide to change to a supplier which already offers a compliant system. | MUST |
STD102-3 | NHS Digital, with the support of users, IT system suppliers, and professional bodies, has produced API (Application Programming Interface) specifications and APIs which enable each system supplier to develop products to send and receive conformant electronic messages: o FHIR (Fast Healthcare Interoperability Resources) message standards transfer the data between systems and locations. o NHS IT system suppliers must use NHS Digital APIs or API specifications to develop for each use case an API to send, receive, and integrate this data regardless of differences between the sending and receiving systems. | MUST |
STD102-4 | IT system suppliers MUST ensure; Integration (machine readability) of the data is achieved by: • using dm+d (dictionary of medicines and devices) codes for medicines • using SNOMED CT (Systemized Nomenclature of Medicine – Clinical Terms) codes for the elements of the dosage instruction, when there are appropriate concepts available in the FHIR UK standard • using dm+d and SNOMED CT codes for allergies/intolerances when there is a suitable coded entry in these terminologies. | MUST |
ID | STD103 |
|---|---|
External ID | N/A |
Version | 1.0 |
Link to standard | |
Standard Type | Guidance |
Status | Alpha |
Effective Date | T |
Description
The DTAC provides a consistent question set and enables you to present the same consistent and proportionate set of evidence to organisations buying your digital health technologies. It sets out the standards expected for entry into the NHS and social care.
Applicability
All new digital technology should be assessed using the DTAC, even if you are piloting or trialling it. If a developer has multiple products, each one would need to be assessed against the DTAC. Examples of products include: staff facing and patient facing digital tech, apps, systems, web based portals, stock control systems, and more.
We have linked the DTAC criteria to the definition of a Health IT System as defined in DCB0129 and DCB0160, being a product used to provide electronic information for health or social care purposes where the product may include hardware, software or a combination of both.
Our initial focus is on embedding the DTAC in the NHS and social care. We will be exploring opportunities for assessment passportablity in the future.
Digital tech already in use does not need to be retrospectively assessed but may need to be assessed at the point of a contract renewal or if commissioned by a different organisation.
Requirements
Requirement ID | Requirement Text | Level |
|---|---|---|
STD103-1 | 1. Clinical safety IT system suppliers products are assessed to ensure that baseline clinical safety measures are in place and that organisations undertake clinical risk management activities to manage this risk. | MUST |
STD103-2 | 2. Data protection IT system suppliers products are assessed to ensure that data protection and privacy is ‘by design’ and the rights of individuals are protected. | MUST |
STD103-3 | 3. Technical assurance IT system suppliers products are assessed to ensure that products are secure and stable | MUST |
STD103-4 | 4. Interoperability IT system suppliers products are assessed to ensure that data is communicated accurately and quickly whilst staying safe and secure. | MUST |
STD103-5 | 5. Usability and accessibility IT system suppliers products are allocated a conformity rating having been benchmarked against good practice and the NHS service standard. | MUST |
ID | STD104 |
|---|---|
External ID | N/A |
Version | 1.0 |
Link to standard | https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/ |
Standard Type | Data Standard (External) |
Status | Alpha |
Effective Date | T |
Description
Data protection is about ensuring people can trust you to use their data fairly and responsibly.
The UK data protection regime is set out in the DPA 2018, along with the UK GDPR. It takes a flexible, risk-based approach which puts the onus on you to think about and justify how and why you use data.
The ICO regulates data protection in the UK. We offer advice and guidance, promote good practice, carry out audits, consider complaints, monitor compliance and take enforcement action where appropriate.
Applicability
If an organisation collects information about individuals for any reason other than your own personal, family or household purposes, you need to comply with GDPR
Requirements
Requirement ID | Requirement Text | Level |
|---|---|---|
STD104-1 | Any organisation that collects personal data on an individual (with the exception of personal, family or household purposes MUST comply with GDPR | MUST |
ID | STD106 |
|---|---|
External ID | N/A |
Version | 1.0 |
Link to standard | |
Standard Type | Data Standard (External) |
Status | Alpha |
Effective Date | T |
Description
ISO 11073 enable communication between medical, health care and wellness devices and external computer systems. They provide automatic and detailed electronic data capture of client-related and vital signs information, and of device operational data.
ISO 11073-91064:2009 specifies the common conventions required for the cart-to-host as well as cart-to-cart interchange of specific patient data (demographic, recording, ECG signal data, ECG measurement and ECG interpretation results.
Applicability
ISO 11073-91064:2009 specifies the content and structure of the information that is to be interchanged between digital ECG carts and computer ECG management systems, as well as other computer systems where ECG data can be stored.
Requirements
Requirement ID | Requirement Text | Level |
|---|---|---|
STD106-1 | IT suppliers EPR systems SHOULD be compliant with the details set out in ISO 11073-91064:2009 to enable electronic data transfer between devices and EPR systems | SHOULD |
ID | STD107 |
|---|---|
External ID | DCB0011 |
Version | 1.0 |
Link to standard | |
Standard Type | Data Standard (NHS) |
Status | Alpha |
Effective Date | TBC |
Description
The MHSDS is a patient level, output based, secondary uses data set which aims to deliver robust, comprehensive, nationally consistent and comparable person-based information for children, young people and adults who are in contact with services for mental health and wellbeing, Learning Disability, autism or other neurodevelopmental conditions.
As a secondary uses data set it re-uses clinical and operational data for purposes other than direct patient care, for example: commissioning, service improvement and service design. It defines the data items, definitions and associated value sets extracted or derived from local information systems.
Applicability
It covers services located in England or located outside England but treating patients commissioned by an English CCG or NHS England specialised commissioner or an NHS-led Provider Collaborative.
Requirements
Requirement ID | Requirement Text | Level |
|---|---|---|
STD107-1
| From 1 October 2021 MHSDS services MUST ensure their IT systems are able to capture the information locally that is intended for use to produce the monthly MHSDS v5.0 extract, as defined in the TOS. This includes information required to derive data items as defined within the standard. | MUST |
STD107-2 | From 1 October 2021 MHSDS services MUST ensure their IT systems are able to derive the data items defined within this standard, where they are not collected directly. This includes mapping of local codes to national codes, and the ability to extract this information as envisaged within this standard, e.g., without interim workarounds. | MUST |
STD107-3 | IT systems suppliers SHOULD review all related documents to fully understand the background, objectives and scope of this information standard. | SHOULD |
STD107-4 | Providers of MHSDS services SHOULD ensure that their IT system suppliers review the TOS and User Guidance to understand the scope and definition of each data item. | SHOULD |
STD107-5 | Providers of MHSDS services SHOULD ensure that their IT system suppliers familiarise themselves with the IDB to understand how data items are grouped for the data submission file. | SHOULD |
STD107-6 | Providers of MHSDS services SHOULD ensure that their IT system suppliers provide tools to enable a ‘data mapping exercise’ to be carried out and where possible complete the mappings to the national codes on behalf of the MHSDS providers. A self assessment System Conformance Checklist tool is available on the NHS Digital website to support this mapping exercise. | SHOULD |
STD107-7 | The MHSDS Data Set v5.0 TOS is a specification for a secondary uses data set. It does not define patient systems. Whilst providers of MHSDS services SHOULD ensure that their IT system suppliers use this data set to support their system development, they SHOULD NOT use the data set exclusively and SHOULD also consider the full requirements of the care setting where it is used. | SHOULD |
STD107-8 | Increase in burden for providers in capturing and extracting the information defined in the TOS as a result of system changes in support of the mandated standard SHOULD be proportionate. | SHOULD |
STD107-9 | When considering potential developments, supporting good data quality MUST be prioritised, in conjunction with minimising the burden on providers. | MUST |
STD107-10 | Providers of MHSDS services MUST ensure that their IT system suppliers include a mechanism to allow providers to identify records where there is a legal requirement to restrict the flow of identifiable information for a patient. | MUST |
STD107-11 | Providers of MHSDS services SHOULD remind their IT system suppliers to ensure that any changes resulting from the implementation of v5.0 are compliant with the safety standards DCB0129 and DCB0160. | SHOULD |
STD107-12 | The SDCS Cloud web page provides guidance relating to data submission. Providers of MHSDS services SHOULD review this web page and the requirements for health and care organisations above. | SHOULD |
STD107-13 | Providers of MHSDS services SHOULD ensure that their IT system suppliers review the Technical Guidance and TOS on the NHS Digital website to understand the data validation rules that will be applied at the data landing platform to all incoming data submission files. Validation rules that are not adhered to may result in appropriate groups or the entire data submission file being rejected, depending on the particular validation rule. | SHOULD |
STD107-14 | From 1 April 2021, providers of MHSDS services MUST ensure that their IT systems have the ability to produce data quality reports to support production of their submission files in line with the TOS. | MUST |