Your browser does not appear to support JavaScript. You may want to try one of the following:
You may want to try one of the following:
If the above does not work, try reloading the page yourself. Note that you will lose any unsaved changes:
shift
control
Show details
Hide details
This form has to be reloaded. This most likely happened because your session has expired, which might take to the login page. (If you think that you shouldn't see this message and that the problem persists, please contact support.)
This implementation guidance provides guidance to support the implementation of the PRSB Diabetes Information Record Standard. General guidance is provided here. Data item specific implementation guidance can be found under the 'context' field. PRSB has carried out a clinical safety review in accordance with DCB0129, which is detailed in the clinical safety case and accompanying Diabetes Information Standards hazard log. This guidance should be used in conjunction with the Risk Mitigation section. This guidance should be used in conjunction with the final report for the Diabetes Information Standards.
1.2 Audience This guidance is intended for anyone implementing and using the PRSB Diabetes Information Record Standard standard. This will include health and social care professionals, IT system suppliers, developers, and implementers.
1.3 Definition and scope of the Diabetes Information Record Standard 1.3.1 What the diabetes information record standard is:
The set of rules and instructions governing the type of information expected within a section, cluster, record entry and element and how it is communicated is defined in the information model under the titles of Description, Cardinality, Conformance and Valuesets.
What is defined is a set of information which should be common to most systems recording information to support a person's direct diabetes care. Information recorded may be drawn from different settings. How information from a person's diabetes apps and devices is transferred to (e.g. via the cloud) and stored in a person's electronic health record for diabetes is out of scope. It is recognised that different local implementations across settings may differ in their level of digital maturity. For example some systems may not be capable, at least at first, of storing/ processing raw a data from diabetes devices or platforms (and using this to calculate and display derived summary statistics). It may be that in such cases initial 'simpler' implementations may preferentially send and receive pre-calculated metrics and preformed graphical representations of the data for display to the end-user (e.g. Ambulatory Glucose Profiles (AGPs) shared as PDFs) with a view to progressing to more complex/ sophisticated implementations later. Further work may need to define different ‘views’ in a diabetes care record of the information for different professionals (and other users, including people with diabetes who use services and those with permissioned proxy access) and local use cases based on the information governance framework which has been published by NHS England. These views should define what information is needed by a professional (or person) in particular circumstances. How the information is presented to professionals and citizens in a shared care record will be dependent on the local systems in place but it should be presented in such a way as to provide maximum benefit for different users (in different roles) in each given use case. There is a complex environment of systems and technology to support diabetes that need to share information and will need to conform with the information and technical standards to do so. There are four broad groups of systems and technology increasing from the micro to macro level for example an app, a device, a local management system at ICS level though to a regional or national system:
a. lifestyle apps for supported self-management.
b. medical devices (including self-monitoring and insulin delivery devices, Point of Care systems in hospitals and systems integrating data from devices e.g. Glooko)
c. specialist diabetes management systems (e.g. My Way Diabetes Health, Hicom’s Diamond and Twinkle).
d. non-diabetes specific health and care record and electronic prescribing and medications administration systems (e.g. Cerner Millenium, Epic, EMIS, TPP SystmOne, Graphnet, Orion, Patient Centred Software, Nourish).
In order for information to be shared between these systems they may need to be adapted to ensure that the information is structured and coded in alignment with the standards.
2.3 Dependencies
2.4 Risk mitigation We recommend system suppliers and local implementers apply further risk mitigations when implementing the PRSB Diabetes Information Record Standard by addressing the risks that have been flagged in the clinical safety case report and hazard log for the standard. Suppliers and implementers should aim to reduce the risk scores to 2, or better, when carrying out clinical risk assessments and developing safety cases for their implementations with respect to DCB0129 and DCB0160. 2.5 Information governance Sound principles of information governance and respecting the privacy of people and their information is paramount. NHS England has published a national Information Governance Framework that needs to be considered when planning implementation. Local agreements should be drawn up between organisations to define information requirements for communication.
2.6 Data quality Data quality and accuracy of coded data entry should be managed in local ‘source’ systems to ensure that information shared with people and professionals through other systems is dependent on the source data quality.
2.7 Context of the information (see also Information Types Standard) It is vital for use of the data that all contextual information is maintained and should not be lost on exchange or import of information. For example, a person with diabetes self-managing their condition at home may record their own blood pressure or conduct self-monitoring of blood glucose (SMBG). They may also be using diabetes devices including CGM, connected insulin pens or ambulatory insulin pumps. In all cases it is important that the full context of the information is known (where and when the measurement was done and by whom or what device). The principle, for PRSB standards, is that for clinical safety and efficacy of communications, the key contextual data described within the PRSB Information Types Standard should be easily accessible to the end-user of any implementation of the Diabetes Information Record Standard. The principle applied in the information model is that where it is important (from a professional perspective) to know who or what device undertook the activity and who or what device recorded the that this is made available to the end-user accessing the record. For every item of information shared it is important that an audit trail is recorded (even if not explicitly stated in the information model). This is set out below (see time stamp and audit trail). 2.8 Information Types Standard [Charlie one pager on Information Types Standard]
2.9 Time stamp and audit trail It is important that an audit trail is recorded for every item of information recorded or shared (even if not explicitly stated in the information model). Each record entry will need to be time stamped from the source system with date and time recorded and the identity of the person making the record. This needs to be viewable in the records themselves where appropriate and via a full audit trail which may be viewable by the end user to enhance transparency.
2.10 Links to other systems and records Effective use of the Diabetes Information Record Standard will require the ability to safely link and share the information recorded by the person or their devices (initially onto proprietary apps, applications or other systems and shared in compliance with the Diabetes Self-Management Information Standard) with the person's electronic health record. How this is done is yet to be determined/ clarified with suppliers but may require integration with the person demographics service API where there is a legal basis to do so (see https://digital.nhs.uk/services/demographics) or other secure methods.
2.11 Coding The Personalised Health and Care 2020 framework for action ( https://www.gov.uk/government/publications/personalised - health - and - care - 2020 ) recommends the use of SNOMED CT and the dictionary of medicines and devices (dm+d). Local decisions need to be made about when these codes are to be used, depending on local system functionality and plans. The current ambition is for SNOMED CT and dm+d to be the primary clinical coding schemes in use in the NHS.
2.14 PRSB Support
The PRSB support service is available for any help, enquiries or issues with the using or implementing the standards. Any feedback on the standard (including proposed changes) resulting from putting the standard into practice would also be welcome. Contact is via support@theprsb.org or Tel: 02045515225.
Updates v 2.0have been made as part of the logical model project to:
Alignment with other completed standards projects since the previous release (Dec 2018).
Maintenance issues logged since the previous release.
Updated more succinct valuesets for many elements for mapping to latest release of SNOMED CT, NHS data dictionary and to align to UK core R4 FHIR profiles
FHIR Target added to represent the link to the UK core FHIR R4 where clinical and technical assurance has taken place
Datatypes added to reflect a logical model
Standard JSON extract exported to SPARX EA and UML entity and attribute diagrams developed
SNOMED Tags added in places where clin i cal agreement of SNOMED CT codes ha s taken place to improve interoperability
Elements decomposed : the data models for clinical concepts have been enhanced to be more structured. Includes:
addition of ‘coded’ and ‘free text’ fields for all coded elements, or
restructuring ( eg ) ‘Patient Address’ to include elements for each line of the address.
This aligns standards closer to the associated technical specifications and therefore makes them more implementable.