STD013 - Child Protection Information Sharing | STD035 - Female Genital Mutilation Enhanced Dataset |
STD062 - NHS Number | STD085 - Core Information Standard |
STD088 - Treatment Function and Main Specialty Standard | STD097 - Outpatient Letter v2.1 |
STD102 - Medicine and Allergy/Intolerance Data Transfer | STD117 - Care Homes View of Shared Care Record |
ID | STD013 |
---|---|
External ID | DCB1609 |
Version | 1.0 |
Link to standard | |
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.
The Child Protection - Information Sharing (CP-IS) programme is delivering a solution to share a specified data set between children's social care and health unscheduled care settings.
Applicability
The scope for CP-IS is currently England Local Authority Children’s Services (Social Care) and unscheduled health care settings. This includes:
Emergency Departments (NHS Trusts)
Minor Injury Units (NHS Trusts)
Walk in Centres (ICS/ICB/Primary Care)
Maternity Units (NHS Trusts) – Unscheduled care GP Out of Hours only (ICS/ICB/Primary Care)
Paediatric Wards (NHS Trusts) – unscheduled care Ambulance Services (Ambulance Trusts)
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 | STD035 |
---|---|
External ID | SCCI2026 |
Version | 1.0 |
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
This standard introduces new requirements to the existing FGM Prevalence Dataset about the information that needs to be captured and shared locally about the women, and what needs to be submitted as a central return. This new information collected is needed to inform FGM Prevention programme, specifically around the following, to help the drive to eradicate the practice, and to provide services and support for women and girls who have had FGM
Applicability
Women identified as having FGM, and specific countries of origin.
All girls and women who are at risk of having FGM performed on them.
In a given community, identify numbers of women and girls, who have undergone FGM in order to plan services.
Providing tools to support law enforcement and identify areas of concern relating to FGM, enabling further investigations and, as appropriate, prosecutions. It should be noted, individual patient identifiable information will not be published in order to achieve this.
Reporting prevalence to other government agencies on the prevalence within a local community (this reporting will not however be at the patient level)
To better inform the ultimate goal of moving towards existing datasets, namely; Maternity Services Dataset (MSDS) Children & Young People’s Health Services Dataset (CYPHS) Child and Adolescent Mental Health Services Dataset (CAMHS)
Requirements
These data items form the FGM Enhanced Dataset information that is required to be collected within the Clinical Audit Platform. Data descriptions and further information can be found here:
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 |
ID | STD062 |
---|---|
External ID | SCCI0052 |
Version | 1.0 |
Link to standard | |
Standard Type | Guidance |
Status | Alpha |
Effective Date | TBC |
Description
This standard provides the specification for use of the NHS Number by NHS bodies and by other organisations providing health and care services in England in partnership with the NHS. It defines how the NHS Number must be used in identifying people receiving health and care services, and in locating and communicating their health and care records and other information pertaining to the planning and provision of their care. The standard sets out how information systems must accept, store, process, display and transmit the NHS Number, and what organisations must do to ensure that they use the NHS Number correctly.
Applicability
This standard applies to all bodies that commission or provide health and care services in England in partnership with the NHS including their relevant system suppliers.
Requirements
Requirement ID | Requirement Text | Level |
---|---|---|
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 |
ID | STD085 |
---|---|
External ID | N/A |
Version | 1.0 |
Link to standard | |
Standard Type | Guidance |
Status | Alpha |
Effective Date |
|
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.
Applicability
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 |
---|
Requirement ID | Requirement Text | Level | |
---|---|---|---|
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:
| ||
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:
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 | STD088 |
---|---|
External ID | DCB0028 |
Version | 1.0 |
Link to standard | |
Standard Type | Data Standard (NHS) |
Status | Alpha |
Effective Date | TBC |
Description
The Treatment Function and Main Specialty Standard covers the Treatment Function and Main Specialty classifications used to support the national reporting and analysis of clinical workforce activity throughout the NHS, through data sets such as the Commissioning Data Sets (CDS).
Treatment Function Codes (TFCs) are a division of clinical work based on main specialities but also incorporating approved sub-specialties and treatment interests used by lead care professionals. This includes special interests and services provided by non-doctors and dentists.
TFCs are used to record, report on, extract and flow activity undertaken, irrespective of the type of Healthcare Professional who performs it, and their use is not restricted to consultants.
Main Specialty is the specialty within which a Consultant is recognised or contracted to the organisation and it is aligned to specialties recognised by the Royal Colleges and Faculties and the General Dental Council. Main Specialties have historically been aligned to the European Specialist Medical Qualifications Order 1995 and European Primary and Specialist Dental Qualifications Regulations 1998, in Anglicised form. It is too soon to say whether professions will continue to be aligned; however changes to the list are governed by the ‘Health Care and Associated Professions’ statutory instruments.
The former ‘National Specialty List’ standard was last updated in 2012. The specific aims of this update are to:
improve data quality by introducing new TFCs for services that are not currently represented as a Treatment Function, enabling commissioning of new services that are not currently represented in the TFC list
re-name TFCs that are considered out-dated
modify the definitions of TFCs that are unclear or no longer accurate
update the list of Main Specialties to ensure that the list is aligned with the relevant statutory instrument
clarify the future scope of TFCs that represent specialised services
update the criteria used to define TFCs
update the standard’s name
define the future update process for TFCs.
Applicability
This standard mandates the use of the updated TFC and Main Specialty Code lists within data sets and collections, in particular CDS. The updated list is available on the NHS Digital website.
This proposal will affect:
Organisations that submit data to CDS, and other data sets which include the TFC or Main Specialty Code data items
Organisations that commission health care services
Third parties who supply the systems used to submit this data
SUS (NHS Digital), who process this data
NHS Data Model and Dictionary, who own the list of TFCs
Data Access Request Service (DARS) customers who use CDS assets, and other data users
Finance divisions and departments within national (e.g. NHS England and NHS Improvement) and local organisations.
The disciplines of all consultants contracted with NHS Organisations under a particular recognised specialty are in scope of the Main Specialty list, as well as non-consultant lead professionals such as midwives, nurses and other care professionals.
TFCs are used to record, report on, extract and flow activity undertaken by all care professionals. The scope and eligibility criteria of the Treatment Functions is set out in the separate ‘Treatment Function Acceptance Criteria’ document.
Equivalent SNOMED CT qualifiers are available for use in documentation metadata, these are shown alongside the relevant TFC or Main Specialty Code. They are not to be used in central returns. It is expected that the preferred terms in the UK realm language reference set will match the TFCs and Main Specialty Codes detailed here. However, Fully Specified Names may differ due to the international use of SNOMED CT.
This standard applies to the NHS in England. Very similar standards exist in other ‘home nations’ of the United Kingdom, however they are separately maintained by the appropriate bodies.
Requirements
Requirement ID | Requirement Text | Level |
---|---|---|
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 |
Health & Care Organisations Requirements
Requirement ID | Requirement Text | Level |
---|
Requirement ID | Requirement Text | Level |
---|---|---|
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 |
ID | STD097 |
---|---|
External ID | PRSB Outpatient letter |
Version | 1.0 |
Link to standard | |
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.
Applicability
The PRSB standard for outpatient letters is designed to improve and standardise the content of outpatient letters so that professionals, patients and carers receive consistent, reliable, high-quality information between clinicians and patients.
Requirements
These requirements are professional, and patient endorsed, and evidence based clinical record standards. These provide the basis for technical (FHIR) specifications produced to enable suppliers to implement technical solutions.
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.
Service Suppliers should include the following data set in implementation of an automatically generated Outpatient letter.
Requirement ID | Requirement Text | Level |
---|---|---|
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 |
ID | STD102 |
---|---|
External ID | N/A |
Version | 1.0 |
Link to standard | |
Standard Type | Data Standard (Internal) |
Status | Alpha |
Effective Date | TBC |
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:
| MUST |
ID | STD117 |
---|---|
External ID | DAPB4022 |
Version | 1.0 |
Link to standard | |
Standard Type | Data Standard (Internal) |
Status | Alpha |
Effective Date | TBC |
Description
NHS Digital (NHSD) commissioned the Professional Record Standards Body (PRSB) to support the Social Care Programme (SCP); by development of (new and existing) national information products to support sharing of an individual’s care information between health and social care. The aim was to incorporate local products developed by the Digital Social Care Pathfinder – the ‘Connecting Care Partnership’– into existing PRSB national standard(s).
The Care Homes View (Of Shared Health and Care Records) is a guidance product that proposes a ‘view’ of the PRSB Core Information Standard (CIS) to be seen by care home staff in CQC registered care homes. It is not a standard in its own right. As such it should be used in conjunction with the PRSB deliverables as developed for the CIS. It is also strictly not designed to define information that residential and nursing homes might contribute to a shared care record or store in their own systems
As part of a shared care record, this information would be ‘read-only’ by care home staff and in practice could be comprised of information shared by various health and social care organisations to populate shared care records. This ‘view’ is the result of a thorough research and consultation process that has been tested with stakeholders including, but not limited to, care home staff and residents, primary and secondary care clinicians, allied health professionals and local authority representatives; via webinars, surveys and robust clinical safety case management.
Applicability
Any systems related to the display of information within care homes.
Requirements
Requirement ID | Requirement Text | Level |
---|---|---|
STD117-1 | See implementation guidance at https://theprsb.org/standards/carehomesview/ | MUST |