STD013

DCB1609

0.1

DCB1609 - Child Protection Information Sharing

Data Standard (NHS)

Draft

TBC

STD013-1

NHS Number

The children’s social care system MUST use a validated NHS number as the unique identifier to send CP-IS information.

MUST

STD013-2

NHS Number Validation

The children's social care system SHOULD undertake NHS number check validation, to ensure NHS numbers entered locally are valid NHS numbers. The actual verification of the NHS number (to confirm the NHS number received is the correct child) will be the responsibility of the CP-IS Service, upon receipt of the CP-IS Local Authority Upload message.

SHOULD

STD013-3

NHS Spine

The children's social care system MAY use the NHS Spine PDS service to verify NHS numbers prior to any submission to the CP-IS service.

MAY

STD013-4

Date and Time format

The presentation of any date & times associated with CP-IS information MUST be in a standardised format, e.g. DD/MM/YYYY and HH/MM/SS

MUST

STD013-5

CP-IS Data Set

The children’s social care system MUST be able to send current and up to date CP-IS information as outlined in the CP-IS dataset, using the CP-IS Local Authority Upload message. Sending of CP-IS information will be undertaken; - as an initial upload of all CP-IS information for each child - as subsequent uploads of all CP-IS information for each child - as subsequent updates of all CP-IS information where a child's CP-IS status has changed

MUST

STD013-6

CP-IS Data Set - Update

Any update to a CP-IS data item within a local record MUST automatically (and without manual intervention) trigger the creation of a CP-IS Local Authority Upload message, in order for this to be sent to the CP-IS service within 12hours of the original change being made. It is anticipated that the SFT client provided, will be embedded within the children’s social care application, and upon creation of the CP-IS Local Authority Upload message will automate the transmission of the CP-IS information via the SFT mechanism to the CP-IS service.

MUST

STD013-7

CP-IS Data Set - Upload Tel Number

Where an 'Office Hours' telephone number is available locally, this SHOULD be included in the CP-IS Local Authority Upload message, in addition to the 'Out of Hours/ Emergency' telephone number. This will assist NHS healthcare workers to easily identify where to contact in non-emergency/ office hours circumstances, and will specifically be useful where a child has presented in out of area settings

SHOULD

STD013-8

CP-IS Data Set - Identify Update

Any update to a CP-IS information locally within a local record SHOULD be easily identifiable

SHOULD

STD013-9

CP-IS Data Set - LA Upload message

Where there is any update to a CP-IS dataset item held locally within the children's social care system, this MUST trigger the creation of a new CP-IS Local Authority Upload message (replacing what is held within the CP-IS service). E.g. the addition of an End Date to a CPP. Any update to a local record that is not a CP-IS data item, SHOULD not trigger the creation of a new CP-IS Local Authority Upload message, e.g. updated assessment information, change of address etc.

MUST

STD013-10

CP-IS Data Set - Messenger Identity

Any update to a CP-IS data item within a local record SHOULD easily identify locally who updated the CP-IS information.

SHOULD

STD013-11

CP-IS Data Set - Schema Validation

The children's social care system SHOULD ensure that prior to any sending of CP-IS information to the CP-IS service, the schema is validated to ensure the message is appropriately formed, and all appropriate fields have been populated appropriately. This will include: - NHS number; Source Organisation Name (Local Authority Name); - Source Organisation Code (ODS Code); - Source Organisation Telephone (Emergency Duty Team/ Out of Hours); - At least one Start Date included for 1 of the 3 CP-IS status types (CPP, Unborn CPP or LAC); - Delete Date (which will be the expected Due Date) where CPP for an Unborn Baby details have been provided.

SHOULD

STD013-12

CP-IS Data Set - Mothers details

The children's social care system MUST ensure that when details of an Unborn CPP are sent, the following demographic information is used to populate the CP-IS Local Authority Upload message: - the Mother's NHS Number; - the Mother's Given Name; - the Mother's Family Name; - the Mother's Date of Birth

MUST

STD013-13

CP-IS Data Set - Birth details

The children's social care system MUST ensure that when details of an Unborn CPP is sent, the expected Due Date for the baby (held locally) is used to populate the Unborn CPP End Date. The End Date (expected due date of the baby) provided will be used to trigger the deletion of the information from the mother’s NHS record at End Date+28days. As part of the wider process, the new-born baby's NHS number will be manually provided to the children's social care team. This will need to be used to resubmit any CP-IS information using the new-born baby’s NHS number, instead of the mother's NHS number.

MUST

STD013-14

CP-IS Data Set - Stop Sending

The children’s social care system MUST allow the sending of CP-IS information, to be switched on and off, at the discretion of the Children’s Social Care Team. This will be managed by end point enabling/ disabling. Where this occurs, the CP-IS Owner (NHS Digital), MUST be informed by the Local Authority management team, that the functional capability to send CP-IS information has been switched off

MUST

STD013-15

CP-IS Data Set - Identify Child Record

It MUST be possible to identify within the children's social care system, the appropriate child record that will have their CP-IS information sent to the CPIS service. E.g. by having an active CP-IS status associated to the local record within the children's social care system

MUST

STD013-16

CP-IS Data Set - Unique File Identifier

The children's social care system MUST ensure that any files sent are sequential and are uniquely identifiable

MUST

STD013-17

CP-IS Data Set - Message Resubmission

The children's social care system SHOULD resubmit a CP-IS Local Authority Upload file if no CP-IS Acknowledgement Response has been received for a CP-IS Local Authority Upload message. This SHOULD be sent if no CP-IS Acknowledgement Response message is received within15hrs of the initial CP-IS Local Authority Upload message being submitted to the CP-IS SFT client

SHOULD

STD013-18

CP-IS Data Set - End Date

Where a child’s case (or child record) is closed locally by the social care team, (and where an End Date for the CP-IS information has not been uploaded to the CP-IS service), then the children's social care system MUST apply End Dates for each of the relevant CPP/UCPP/LAC items within that child’s case (or child record). The End Date will be the date that a child’s case (or child record) is closed. The application of the End Date to the record, will trigger the submission of a CP-IS Local Authority Upload message outlining all associated End Dates for that record. In the case of the initial bulk upload of records to the CP-IS Service, a child record MUST not be included in the upload message when it is closed or when the CPP or LAC record has an End Date that is in the past at the point of data extraction / submission to CP-IS. Where there are multiple CPP and/or LAC records for one child and if one or more CPP, UCPP or LAC record has an End DCB1609 Child Protection Information Sharing 31/05/2019 Final v2.0 Copyright © 2019 Health and Social Care Information Centre. Page 18 of 35 Date in the past, only those records without an End Date in the past are to be sent to the CP-IS Service. For example in the case of a child that has a LAC record with an End Date of 6 weeks ago and a CPP record that has a Start Date of 5 weeks ago and no End Date, only the CPP record would be sent to the CP-IS Service. Following the bulk upload, for reconciliation purposes, a report MUST be made available to the end user which will list the CPP, UCPP and LAC records that were not successfully uploaded to the CP-IS Service due to the End Date being in the past

MUST

STD013-19

CP-IS Data Set - Local Configuration

The children's social care system MUST be able to manage the receipt of the following CP-IS messages and display the content of these messages to the end user. How the display of this information will be provided, will need to be locally defined and configured to the children's social care team’s requirements. The CP-IS messages to the children's social care system will include: - CP-IS Local Authority Acknowledgment Response (which includes file and record validation responses); - CP-IS Access to Service Notification (which includes who, when, where the CP-IS service was queried); - CP-IS Inactive NHS Number Notification (where available the new NHS Number will be provided).

MUST

STD013-20

CP-IS Data Set - Acknowledgment Response

On receipt of a CP-IS Local Authority Acknowledgement Response message, the children's social care system MUST determine the file and record validation responses of the CP-IS Local Authority Upload message. Where all records are successfully uploaded, consideration SHOULD be given to how the successful uploads are replayed to the end user, if this is required. Where records within the Upload message are not successfully uploaded, consideration SHOULD be given to how the unsuccessful uploads will be handled by the children's social care system and/ or end user. E.g. unverified NHS numbers and the associated reasons for that number not being uploaded to the CP-IS service, being displayed to the end user.

MUST

STD013-21

CP-IS Data Set - Display of Information

On receipt of a CP-IS Access to Service Notification message, the children's social care system SHOULD be locally configured to determine how this information will be displayed to the end user. This will include the following information: - the name of the NHS healthcare worker (in a readable format) who accessed the CP-IS service; - the name of the NHS organisation (in a readable format) where the access to the CP-IS service took place; - the date and time of when the CP-IS service was accessed. Access to Service Notification messages will be provided daily to the children's social care system, including all access event history for all the associated children to that Local Authority, specifically including where there has been no access to the CP-IS service for that day. On receipt of a CP-IS Access to Service Notification message, consideration SHOULD be given to how this information will be displayed to the end user, including any alerting functionality. Further to this, consideration SHOULD also be given to how the receipt of the access history will be managed in the following scenarios; 1. Where ‘no access’ event history is received, and whether this daily information SHOULD be displayed to the end user; 2. When an End Date is; - received as part of a typical Start/ End Dating of CP-IS information automatically created by the CP-IS service on the child's 18th birthday - automatically provided by the children’s social care system, upon closure of a case/ record locally. Following the capture of an End Date for a CP-IS information item (however this is done), the CP-IS item will still be retrievable by the NHS healthcare worker up to the End Date +365 days. Any access to CP-IS service during this 365 day period, will result in the creation of a CP-IS Access to Service Notification message back to the children's social care team.

SHOULD

STD013-22

CP-IS Data Set - Inactive NHS Number

On receipt of a CP-IS Inactive NHS Number message, the children's social care system MUST be able to inform the end user that the NHS number previously used to submit CP-IS information to the CP-IS service is no longer a valid NHS number. The children’s social care system MUST also inform the end user of the new NHS number, where this has been included within the Inactive NHS number message. Where Inactive NHS number information is received, consideration SHOULD be given to how this information is displayed to the end user

MUST

STD013-23

CP-IS Data Set - Update NHS Number

On receipt of a CP-IS Inactive NHS Number message that includes details of the new NHS number, the children's social care system MAY want to automatically update the NHS number within the local system.

MAY

STD013-24

CP-IS Data Set - Update Message

On receipt of a CP-IS Inactive NHS Number message that includes details of the new NHS number, the children's social care system MAY want to automatically create and resubmit a new CP-IS Local Authority Upload message using the new NHS number

MAY

STD013-25

CP-IS Data Set - Local Authority Connection

Only authorised Local Authority end-points MUST be permitted to connect to the CP-IS service. The mechanism for doing so may vary between systems that consume webservices to those that submit Local Authority data

MUST

STD035

SCCI2026

0.1

SCCI2026: Female Genital Mutilation Enhanced Dataset - NHS Digital

Data Standard (NHS)

Draft

STD035-1

Suppliers of IT and software systems to NHS organisations MUST ensure that where SNOMED CT, CTV3, Read or OPCS is currently supported, the FGM clinical classifications and clinical codes related to FGM can be recorded against health records by Apr 2015. These codes will be the existing FGM codes as published in April 2014

MUST

STD035-2

Suppliers of IT and software systems to NHS organisations MUST ensure that where SNOMED CT, CTV3, Read or OPCS is currently supported, the new FGM clinical classifications and clinical codes related to FGM can be recorded against health records by Oct 2015. The new FGM codes will be published in April 2015 specifically;  History of Deinfibulation  History of FGM Type 3 These codes are detailed further within this document

MUST

STD035-3

Suppliers of IT and software systems to NHS organisations MAY ensure that the new FGM clinical codes to be published in Apr 2015, (and detailed further within this document), can be recorded against health records from April 2015

MAY

STD035-4

Suppliers of IT and software systems to NHS organisations MAY ensure that the relevant FGM Enhanced dataset can be recorded within existing systems from April 1 st 2015.

MAY

STD035-5

Suppliers of IT and software systems to NHS organisations MUST ensure that the relevant FGM information can be recorded locally within existing systems by Dec 2015.

MUST

STD035-6

Suppliers of IT and software systems to NHS organisations MUST ensure that it is possible to extract the relevant FGM information from their systems by Information Teams or Practice Managers, enabling the update of the FGM Enhanced dataset submission to HSCIC.

MUST

STD062

SCCI0052

0.1

ISB 0149

Guidance

Draft

TBC

STD062-1

MUST be capable of storing the NHS Number as described in the NHS Data Dictionary on patient/service user records.

MUST

STD062-2

MAY indicate whether/when the currently stored NHS Number has been verified by checking against the Personal Demographics Service.

MAY

STD062-3

MUST allow users to find a patient/service user record using the NHS Number as the only search criterion.

MUST

STD062-4

MAY allow users to find a patient/service user record using the NHS Number as part of the search criteria in conjunction with other demographic information

MAY

STD062-5

MUST allow users to find a patient/service user record without using the NHS Number as part of the search criteria.

MUST

STD062-6

MUST include the NHS Number in any patient identifiable data/service user information sent electronically, with the following exceptions: • The NHS Number is not available at time of transmission. • The use of the NHS Number is in conflict with other requirements, standards, legislation, common law duty of confidentiality or policies.

MUST

STD062-7

MUST display the NHS Number on every screen showing patient identifiable data/service user information (if available). The verification status of the NHS Number SHOULD also be displayed if maintained.

MUST

STD062-8

MUST include the NHS Number on all hard-copy outputs containing patient identifiable data/service user information (if appropriate and available at time of output).

MUST

STD062-9

MUST display and print the NHS Number for people to read in 3 3 4 format (e.g. 123 456 7890).

MUST

STD062-10

MUST allow the NHS Number to be input into the appropriate data input field on the screen as 10 digits with or without spaces.

MUST

STD062-11

MUST validate (both format and check-digit) the NHS Number when input.

MUST

STD062-12

MUST be capable of reporting where the same NHS Number (verified or not) is recorded on more than one patient/service user record.

MUST

STD062-13

SHOULD be capable of reporting all patient/service user records without an NHS Number recorded.

SHOULD

STD062-14

When a system user uses the NHS Number to retrieve an electronic record other demographic information supplied MUST be used to confirm the patient’s/service user’s identity and that the record retrieved belongs to that patient/service user

MUST

STD062-15

When supplied, the NHS Number SHOULD be used instead of demographic data as the patient/service user identifier.

SHOULD

STD062-16

Data quality processes SHOULD be in place to resolve electronic patient/service user records where the same NHS Number (verified or not) is recorded on more than one record.

SHOULD

STD062-17

Organisations MUST ensure all staff are trained in the correct use of information management technology systems, human behaviours and business processes required to support this Standard.

MUST

STD062-18

At the start of each new episode of care or contact, or at the earliest opportunity the patient’s/service user’s demographic data, including NHS Number SHOULD be confirmed with the patient/service user or his/her parent or carer or other organisations working with the patient/service user.

SHOULD

STD062-19

The patient’s/service user’s NHS Number SHOULD be determined at the beginning of (or prior to) the episode of care, where possible and practical.

SHOULD

STD062-20

The parent or guardian MUST be given written confirmation of the NHS Number of a newborn child following allocation via the statutory notification of birth (through NHS Number for Babies Service (NN4B)) or the Personal Demographics Service (PDS).

MUST

STD062-21

The patient’s/service user’s NHS Number SHOULD always be included as part of all communications, correspondence and filing systems involving patient/service user identifiable data/service user information. Additional patient/service user demographic information MUST also be included with the NHS Number.

SHOULD

STD062-22

Organisations MUST promote the importance and use of the NHS Number to all staff.

MUST

STD062-23

Organisations MUST have processes in place to support patients/service users to know their NHS Numbers and to supply it to them when requested.

MUST

STD085

N/A

0.1

The Core Information Standard

Guidance

Draft

STD0085-1

Information Components 

 Model Description 

SHOULD

Section 

A section groups together all the information related to a specific topic e.g. ‘Medications and medical devices’ and ‘Person demographics’.  

It is the highest level to logically group data elements that may be independent or related. For example: 

• ‘Legal information’ includes a set of independent elements or information items, grouped in a logical section.  

• ‘Medications and medical devices’ includes sets of related elements with dependencies between the elements.  

Record entry 

A record entry within a section is used where a set of information is repeated for a particular item, and there can be multiple items. For example, for each medication there is a set of information associated with that medication. Other examples are allergies or adverse reactions and procedures.   

Cluster 

This is a set of elements put together as a group and which relate to each other; e.g. medication course details cluster which is the set of elements describing the course of the medication.   

Element  

The data item.  

An element can appear in one or more sections e.g. name, date.  

Information model rules and instructions 

Explanations 

Description   

This is the description of the section, record entry, cluster or element.  For an element, it describes the information that the element should contain in as plain English as possible.   

Cardinality  

Each section, record entry, cluster and element will have a statement of cardinality. This clarifies how many entries can be made i.e. zero, one or many entries. The number of records expected and allowed are displayed as: 

0……* = zero to many record entries are allowed 

0……1 = zero to one record entry is allowed 

1……1 = one record is expected   

1……* = one to many records are expected 

For example, the ‘Medications and medical devices’ section may have zero to many medication item records in it and is displayed as 0…… *.   

Conformance  

Conformance defines what information is ‘mandatory’, ‘required’ or ‘optional’ and applies to sections, record entries, clusters and elements. 

The IT system must be developed to handle all the information elements that are defined in the Standard but not all the information is required for every individual record or information transfer.  

The following set of rules apply to enable implementers to cater for the end users (senders and receivers) requirements:  

• Mandatory – the information must be included  

• Required – if it exists, the information must be included  

• Optional – a local decision is made as to whether the information is included 

These rules apply at all levels and give the flexibility to allow local clinical or professional decisions on some information that is included, while being clear on what is important information to include.   

For example, a person subject to a referral may have many assessments, but not all of these will be relevant to the referral.  The conformance can be used to allow just relevant assessments to be included.  

Assessment Section – Required – i.e. its important information you must include if you have it. 

Record entry level – Optional – allows a local decision on what assessments are included, so only relevant ones are included based on clinical or professional needs.   

Assessment elements – Conformance set on the normal basis of which elements for an assessment are mandatory, required or optional.   

NB: It is permitted to upgrade a conformance rule but not to down grade one. For instance, a section that is classed as optional in the standard can be upgraded to required or mandatory in local implementations. However, one that is classed mandatory or required cannot be downgraded to required or optional.  

Valuesets  

Valuesets describe precisely how the information is recorded in the system and communicated between systems. This is required for interoperability (for information to flow between one IT system and another). 

The information can be text, multi-media or in a coded format. If coded it can be constrained to SNOMED CT and specific SNOMED CT reference sets, NHS Data Dictionary values or other code sets.  

STD088

DCB0028

0.1

DCB0028 Guidance (NHS Digital)

Data Standard (NHS)

Draft

TBC

STD088-1

From 1 April 2021 relevant suppliers systems MUST be fully conformant with this standard, i.e. able to collect the updated TFCs and Main Specialty Codes.

MUST

STD088-2

From 1 April 2021 suppliers systems SHOULD allow the extraction of the updated TFCs and Main Specialty Codes, as required in any data sets or collections mandated through separate ISNs.

SHOULD

STD088-3

Changes made to suppliers systems SHOULD result in minimal increased burden for care providers in recording and extracting the Treatment Function and Main Specialty information, and any additional burden SHOULD be proportionate.

SHOULD

STD088-4

Suppliers using, configuring and/or designing systems SHOULD review all related documents to fully understand the background, objectives and scope of this information standard.

SHOULD

1

From 1 April 2021 care providers MUST be able to collect the updated TFCs and Main Specialty Codes for local use.

MUST

2

From 1 April 2021 care providers SHOULD be able to submit the updated TFCs and Main Specialty Codes, as required in any data sets or collections mandated through separate ISNs. Care providers MAY also need to submit the previous TFCs and Main Specialty Codes in the event that other standards which use these data items are yet to be updated. Section 5.4 of the Implementation Guidance describes this in more detail.

SHOULD

3

Upon publication of this Information Standard, providers SHOULD review this Requirements Specification to fully understand the background, objectives and scope of this information standard and establish the impact on their local systems and data flows.

SHOULD

4

Upon publication of this Information Standard providers SHOULD review the updated lists of TFCs and Main Specialty Codes in order to understand any local system configuration activity required in order to record the updated codes.

SHOULD

5

Upon publication of this Information Standard, providers SHOULD inform their commissioners of the changes and discuss the implementation with them.

SHOULD

6

To support the implementation of this information standard, care providers SHOULD highlight any issues with the TFC and Main Specialty Code data items and feed these back to the standard’s developers and the Treatment Function Maintenance Group. Requests for new TFCs, or amendments to existing TFCs, should be made by emailing enquiries@nhsdigital.nhs.uk including ‘Request for new TFC’ in the subject line.

SHOULD

STD097

PRSB Outpatient letter

0.1

https://theprsb.org/standards/outpatientletterstandard/

Data Standard (NHS)

Draft

TBC

STD097-1

Patient name

MUST

STD097-2

Patient preferred name

SHOULD

STD097-3

Date of birth

MUST

STD097-4

Gender

SHOULD

STD097-5

NHS number

SHOULD

STD097-6

Other identifier

SHOULD

STD097-7

Patient address

MUST

STD097-8

Patient email address

MAY

STD097-9

Patient telephone number

MAY

STD097-10

Relevant contacts

MAY

STD097-11

Educational establishment 

MAY

STD102

N/A

0.1

DAPB4013 - Medicine and Allergy/Intolerance Data Transfer

Data Standard (Internal)

Draft

TBC

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

STD117

DAPB4022

0.1

Care Homes View of Shared Care Record

Data Standard (Internal)

Draft

TBC

STD117-1

See implementation guidance at https://theprsb.org/standards/carehomesview/

MUST