Patient Admission from Primary Care, Emergency Admission
ID | STD013 |
---|---|
External ID | DCB1609 |
Version | 0.1 |
Link to standard | |
Standard Type | Data Standard (NHS) |
Status | Draft |
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 | STD019 |
---|---|
External ID | N/A |
Version | 0.1 |
Link to standard | |
Standard Type | Guidance |
Status | Draft |
Effective Date | TBC |
Description
The Emergency Care Data Set (ECDS) collects information about why people attend emergency departments and the treatment they receive to
improve patient care through better and more consistent information
allow better planning of healthcare services
improve communication between health professionals
Applicability
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 |
---|---|
External ID | SCCI2026 |
Version | 0.1 |
Link to standard | SCCI2026: Female Genital Mutilation Enhanced Dataset - NHS Digital |
Standard Type | Data Standard (NHS) |
Status | Draft |
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 |
MAY
ID | STD064 |
---|---|
External ID | ISB0149-02 |
Version | 0.1 |
Link to standard | |
Standard Type | Data Standard (NHS) |
Status | Draft |
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.
Applicability
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 |
---|---|
External ID | DCB3017 |
Version | 0.1 |
Link to standard | |
Standard Type | Data Standard (NHS) |
Status | Draft |
Effective Date |
|
Description
The Overseas Visitor Charging Category (OVCC) must be used to record the chargeable status of a patient using NHS services.
Applicability
This information standard sets out the values which must be used in the recording of relevant information by providers of NHS-funded services in scope of the National Health Service (Charges to Overseas Visitors) Regulations 2015, most recently amended by the National Health Service (Charges to Overseas Visitors) (Amendment) Regulations 2017. These Regulations mandate the identification, charging and recovery of costs from those patients who are not entitled to use the NHS for free.
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)
| 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 |
---|---|
External ID | DCB1567 National Joint Registry Data Set |
Version | 0.1 |
Link to standard | |
Standard Type | Data Standard (NHS) |
Status | Draft |
Effective Date | TBC |
Description
The national data set for joint replacement surgery and joint replacement implants.
Hip, knee, ankle, elbow and shoulder joint replacements have become common operations, using a wide range of implants. The NJR helps to monitor the performance of these implants and the effectiveness of different types of surgery, improving clinical standards and benefiting patients, clinicians and the orthopaedic sector as a whole.
Applicability
The NJR currently collects data on hip, knee, ankle, elbow, and shoulder joint replacement surgery and now monitors implant, surgical team, and hospital performance in order to ensure patient safety and provide stakeholders with information that will lead to improvements in outcomes. The outcomes of surgical practice are reported to clinicians and trust management. The NJR works closely with regulators: Medicines and Healthcare products Regulatory Agency (MHRA), the Care Quality Commission (CQC), and the National Institute of Health and Care Excellence (NICE). It also works with other organisations such as NHS Choices and the British Orthopaedic Association (BOA)
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 |
---|---|
External ID | PRSB THE CORE INFORMATION STANDARD |
Version | 0.1 |
Link to standard | |
Standard Type | Guidance |
Status | Draft |
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.
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 | |
---|---|---|---|
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:
| ||
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 | STD091 |
---|---|
External ID | DAPB4042 |
Version | 0.1 |
Link to standard | |
Standard Type | Data Standard (NHS) |
Status | Draft |
Effective Date | TBC |
Description
An information standard to establish consistency in the creation and issue of transfer of care acute inpatient discharge documents.
Applicability
The Transfer of Care - Acute Inpatient Discharge is applicable for all ordinary admission and day case admissions. It should be considered for adoption by the specialty using the patient classification “regular day admission” or “regular night admission” based on the value and frequency of GP correspondence currently being generated at the end of each treatment session, and as agreed with the commissioning organisation.
Requirements
These requirements are intended for Supplier Implementation and must be assured via an ITK3 test harness.
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 |
---|---|
External ID | PRSB Outpatient letter |
Version | 0.1 |
Link to standard | |
Standard Type | Data Standard (NHS) |
Status | Draft |
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.
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 |