Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Patient Admission from Primary Care, Emergency Admission

ID

STD013

Name

Child Protection Information Sharing

External ID

DCB1609

Version

0.1

Link to standard

DCB1609 - Child Protection Information Sharing

Standard Type

Data Standard (NHS)

Status

Alpha

Effective Date

TBC

Description

This is the Information Standards Notice for Child Protection - Information Sharing (CP-IS), a national programme delivering a solution to share a specified data set between children's social care and health unscheduled care settings.

...

This standard will help health and social care staff to share information securely to better protect society's most vulnerable children and support decision making when a vulnerable child presents for care.  CP-IS is a national solution for England that will also deal with the issues of migration of children across local boundaries as information will be shared between social care and health nationally leading to better outcomes for vulnerable children who may have otherwise have gone undetected.

Requirements 

Requirement ID

Requirement Text

Level

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

ID

STD019

Name

Emergency Care Dataset

External ID

N/A

Version

0.1

Link to standard

Emergency Care Data Set

Standard Type

Guidance

Status

Alpha

Effective Date

TBC

Description

The Emergency Care Data Set (ECDS) collects information about why people attend emergency departments and the treatment they receive to

...

All providers of Type 01, 02 and 03 Emergency Care Departments

Requirements 

Requirement ID

Requirement Text

Level

STD019-1

All providers of Type 01, 02 and 03 Emergency Care Departments MUST submit ECDS 6.2.3 to SUS+ on a daily basis, using MESH to allow collection and extraction in the required manner, from 1st April 2021.

This amendment takes effect from 1st April 2021.

Full details of data required and formats cane be found here

MUST

ID

STD035

Name

Female Genital Mutilation Enhanced Dataset

External ID

SCCI2026

Version

0.1

Link to standard

SCCI2026:

Female Genital Mutilation Enhanced Dataset

- NHS Digital

Standard Type

Data Standard (NHS)

Status

Alpha

Effective Date

 

Description

SCCI 2026 Implementation Guidance | FGM Enhanced Dataset

...

SCCI 2026 Implementation Guidance | FGM Enhanced Dataset

Requirement ID

Requirement Text

Level

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

MAY

ID

STD064

Name

NHS Number for Secondary Care

External ID

ISB0149-02

Version

0.1

Link to standard

ISB 0149 NHS Number for Secondary Care

Standard Type

Data Standard (NHS)

Status

Alpha

Effective Date

 

Description

The aim of the NHS Number for Secondary Care standard is to increase NHS Number usage within Trusts, ensuring that the patient is correctly associated with their unique NHS Number.

...

  • All information systems supporting the commissioning or provision of NHS Services that hold patient/service user demographic data.

  • All information systems supporting the commissioning or provision of health and care services that are used to transfer or otherwise communicate patient/service user information with other bodies that commission or provide health and care services in England in partnership with the NHS.

  • All new information systems procured after this standard comes into force. • All existing information systems where it is reasonably practicable, given cost and other constraints, to upgrade it to comply with this standard.

  • All existing or new information systems where the use of the NHS Number would not compromise patient/service user care nor provide a barrier to the uptake of care services – this to be determined by a local clinical risk assessment

Requirements 

Requirement ID

Requirement Text

Level

STD0064-1

Verification Status

Applicable Systems must record the verification status of each recorded NHS Number. A verified NHS number has been cross-checked using demographic details on the Personal Demographics Service (PDS)

MAY

STD0064-2

Electronic Communication

Only verified NHS numbers should be sent electronically

SHOULD

STD0064-3

Hard Copy Output

Only verified NHS numbers should be be used when sending a hard copy output

SHOULD

ID

STD066

Name

Overseas Visitor Charging Category (OVCC)

External ID

DCB3017

Version

0.1

Link to standard

DCB3017: Overseas Visitor Charging Category (OVCC)

Standard Type

Data Standard (NHS)

Status

Alpha

Effective Date

 

Description

The Overseas Visitor Charging Category (OVCC) must be used to record the chargeable status of a patient using NHS services.

...

In support of this requirement, this new information standard states that the attribute, OVERSEAS VISITOR CHARGING CATEGORY, must be used to record the chargeable status of a patient using NHS services where this information is recorded.

Requirements 

Requirement ID

Requirement Text

Level

STD0066-1

Where it is recorded, the OVCC of a patient is stored under consistent categories.

MUST

STD0066-2

An additional charging category is necessary to allow for the recording of “Decision Pending” and “Not Known” as separate and relevant categories. T

MUST

STD0066-3

The OVCC attribute will have eight categories, each with a letter code:

The standard does not flow information as this will simply be a reference file of OVCC visible on local systems and NHS Trust systems (including for monitoring patients)

  • A - Standard NHS-funded Patient

  • B - Immigration Health Surcharge payee

  • C - Charge-exempt Overseas Visitor (European Economic Area)

  • D - Chargeable European Economic Area Patient

  • E - Charge-exempt Overseas Visitor (non-European Economic Area)

  • F - Chargeable non-European Economic Area Patient

  • P - Decision Pending

  • 9 - Not Known

MUST

STD0066-4

These categories should also be used if transcribing onto Summary Care Record application (SCRa)

SHOULD

STD0066-5

When data is recorded it must be recorded using the categories as listed above (A-F, P and 9).

MUST

Emergency Admission

ID

STD056

Name

National Joint Registry Data Set

External ID

DCB1567 National Joint Registry Data Set

Version

0.1

Link to standard

DCB1567 National Joint Registry Data Set

Standard Type

Data Standard (NHS)

Status

Alpha

Effective Date

TBC

Description

The national data set for joint replacement surgery and joint replacement implants.

...

The organisations affected by this are: NHS Trusts • NHS Foundation Trusts • Independent healthcare sector hospitals

 

Requirements 

Requirement ID

Requirement Text

Level

STD056-1

Registration and System Access. All users MUST be registered to use the data entry system before either entering data or accessing the reports available on the system

MUST

STD056-1

All users MUST use the registration process outlined on the NJR website (http://www.njrcentre.org.uk )

MUST

STD056-2

Following verification of registration requests, users MUST supply a password and piece of memorable information as part of the registration process.

MUST

STD056-3

All users MUST enter data either via the NJR Data Entry System as described in the ‘Data Entry User Guide’ or by use of the Bulk Upload facility. Guidance for both can be found on the NJR website at http://www.njrcentre.org.uk

MUST

STD056-4

Pre-Assessment and Patient Consent. Patients MUST be given information about the NJR either before or during pre-assessment clinics, using the NJR Patient Information Leaflet where available.

MUST

STD056-5

All patients MUST be offered the opportunity to consent to their personal data being recorded and stored by the NJR and MUST be given a copy of the NJR Patient Consent Form which is available either as hard copy from the NJR Centre or as a download from the NJR website (http://www.njrcentre.org.uk )

MUST

STD056-6

An NJR record MUST be submitted for each (sic) replacement, revision, excision, conversion, amputation, procedure, hybrid, debridement, implant, resurfacing, glenoid procedure, performed by the orthopaedic unit.

MUST

STD056-7

Patient consent can be recorded in one of three ways: ‘Yes’; ‘No’; ‘Not Recorded’. Where ‘Yes’ and ‘Not Recorded’ are indicated for consent, the system requires patient identifiable data to be entered. Whilst ‘Name’ and ‘Date of Birth’ are mandatory, either ‘Postcode’ or ‘NHS/National Patient number’ must be provided.

SHOULD

ID

STD085

Name

The Core Information Standard

External ID

PRSB THE CORE INFORMATION STANDARD

Version

0.1

Link to standard

Core-Information-Standard

Standard Type

Guidance

Status

Alpha

Effective Date

TBC

Description

The Core information standard defines a set of information that can potentially be shared between systems in different sites and settings, among professionals and people using services.

...

This guidance is intended for anyone implementing the core information standard. This will include project teams (including clinicians, other care professionals and people who use services) involved in building systems that will use the core information standard and system suppliers.

 

Requirements 

Requirement ID

Requirement Text

Level

STD0085-1

 

Information Components 

 Model Description 

MUST

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.  

ID

STD091

Name

Acute Inpatient Discharge Standard

External ID

DAPB4042

Version

0.1

Link to standard

DAPB4042 Acute Inpatient Discharge Standard

Standard Type

Data Standard (NHS)

Status

Alpha

Effective Date

TBC

Description

An information standard to establish consistency in the creation and issue of transfer of care acute inpatient discharge documents.

...

See further implementation guidance here- DAPB4042:Implementation guidance

Requirement ID

Requirement Text

Level

STD091-1

The Supplier Software has the ability to send an Inpatient and Day Case Discharge Summary - an ITK3 FHIR document containing Transfer of Care information supporting an inpatient and day case discharge.

The document would need to be sent by any secondary care provider (NHS or independent sector) contracted under the terms of the NHS Standard Contract. The recipient would be the registered General Medical Practice of the patient

MUST

ID

STD097

Name

PRSB Outpatient letter

External ID

Version

0.1

Link to standard

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

Standard Type

Data Standard (NHS)

Status

Alpha

Effective Date

TBC

Description

PRSB standards for digital outpatient letters allow clinical information to be recorded, exchanged and accessed consistently across care settings. Best practice for most outpatient letters is writing directly to patients.

...

These requirements describe the Patient demographics section of a patient letter. The full data specification for all sections can be found here; Introduction to ITK3 Outpatient Letter.

Requirement ID

Requirement Text

Level

Suppliers software must provide the patient information stated int he requirements below:

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