Version 1.2, October 2015.
TABLE 13
The PADDS system technical specifications: document history
View in own window
| Date | Version | Authors | Description |
|---|
| 5 August 2015 | 0.0 | Valentina Lichtner | First draft, for discussion |
| 21 August 2015 | 0.1 | José Closs | Review and comments |
| 27 August 2015 | 1.0 | Valentina Lichtner | Edits in response to review. Added section 2.4. Completed first draft of Appendix |
| 14 September 2015 | 1.0 | Dawn Dowding | Comments to requirements FR.02, FR.05, FR.09, FR.p-a.01 |
| 21 September 2015 | 1.1 | Valentina Lichtner | Edits in response to review |
| 22 September 2015 | 1.1 | SSC | Comments to requirements , FR.09, FR.p-a.03 |
| 5 October 2015 | 1.2 | Valentina Lichtner | Edits in response to SSC comments |
TABLE 14
The PADDS system technical specifications: forecast changes
View in own window
| Anticipated change | When |
|---|
| The requirements specification for the PADDS system are expected to change as a result of the feasibility evaluation of the system in use | Feasibility evaluation planned for 2016, to be confirmed |
Documents generated by this study providing additional information.
TABLE 16
The PADDS system technical specifications: glossary of terms
View in own window
| Term | Acronym | Definition |
|---|
| Computerised Decision Support System | CDSS | Also known as Clinical Decision Support System |
| CDSS are ‘active knowledge systems which use two or more items of patient data to generate case-specific advice’159 |
| CDSS refer specifically to electronic tools in support of decision making. For a more general definition of decision support tools, not limited to computerised ones, see Decision Support System (DSS) |
| Decisions Support System | DSS or DST | Also known as decision tool |
| A tool that helps clinicians to make the right decision for the right patient at the right time. Mechanisms for decision support may include: templates to guide data acquisition, algorithms, provision of guidance, default options, or the display of ‘a snapshot of a patient’s disease state’.160 Such tools may, or may not, be computerised |
| For a definition of computerised DSS, see CDSS |
| Early Warning Score | EWS | A process and chart to record observations of a patient’s physiological parameters and score allocated to their measurement. It often includes a section related to pain – and a pain score – as a ‘fifth vital sign’. A national version is available161 (the NEWS) to standardise these systems across the NHS acute settings; however, modified versions (also known as MEWS) are also in use |
| See also EWS and MEWS |
| Electronic Patient Record | EPR | Patients’ clinical notes recorded on a digital system. The record includes medical notes; it may include nursing notes; it may also include (or link to systems for) orders and/or results for lab tests, digital pictures of scans, medical prescriptions |
| Electronic prescribing | ePrescribing | Electronic systems to support both the prescribing of medicines and ‘facilitate and enhance the communication of a prescription or medicine order, aiding the choice, administration and supply of a medicine through knowledge and decision support and providing a robust audit trail for the entire medicines use process’111 |
| Electronic Prescribing and Medicine Administration system | EPMA | Electronic systems to support both the prescribing of medicines and their administration to patients in acute settings. Medicine administration may include the use of barcodes on both patients’ wristbands and on medicines, and barcode scanners to match patients to their medicines |
| Health-care assistant | HCA | Assistant practitioners, usually to nurses, with tasks of direct patient care involving activities of daily living (e.g. assisting patients with meals or bathing) in acute settings. They may also be responsible for periodic observations of patients’ vital signs and recording EWS |
| Health-care professional | HCP | A nurse, doctor, pharmacist, therapist or other member of the clinical team caring for patients in hospital |
| Modified Early Warning Score | MEWS | See EWS |
| Multidisciplinary team | MDT | The group of HCPs and HCAs who care for a patient at any given time |
| National Early Warning Score | NEWS | See EWS |
| Patient Administration System | PAS | Information system for the administration of a hospital’s clinical activities, such as bookings of appointments or recording of hospital admissions; usually the main source of patients’ demographic information used within other clinical systems |
| Patient’s Passport | | A form to be used by patient’s family members to describe the person’s likes and dislikes and usual behaviour. These forms are usually paper based and variably known as, for example, ‘Patient passports’, ‘10 things about me’, ‘Know who I am’ |
Contents
View in own window
| Summary |
About this document Purpose Definition Audience Expected benefits
Introduction Use and interconnections with other systems Requirements Usability and safety Functional requirements
Hypotheses and rationales for system design
|
Summary
This document contains the specifications for a set of functional requirements for an electronic decision support system to assist with the recognition, assessment and management of pain, specifically for patients with dementia. We call this a Pain And Dementia Decision Support (PADDS) system. The system as outlined in these requirements is intended to be used primarily in hospital settings.
The requirements outlined in this document emerged out of an in-depth exploratory study conducted in three acute NHS trusts in England and one acute NHS board in Scotland, through research funded by the NIHR HSDR programme (HSDR – 11/2000/05). These specifications are intended as a first set of requirements to guide software development for the PADDS.
It is expected that in the first instance the PADDS system will be developed within a single hospital organisation which has ward-based EHRs. The PADDS system will then be tested for usability and feasibility.
These requirements specifications are to be revised, amended and completed once the system has been put in place and its use, usability and clinical utility evaluated.
1. About this document
1.1 Purpose
This document describes the functional requirements of an electronic Pain And Dementia Decision Support (PADDS) system.
1.2 Definition
A PADDS system is an electronic system aimed at aiding the recognition, assessment and management of pain in patients with dementia. It may be implemented in acute wards within a complex improvement intervention, including changes to the organisation of care and documentation practices (also known as a PADDS intervention).
1.3 Audience
This document is aimed at software developers and is intended to guide the design and building of the PADDS system.
It may be of interest to managers, healthcare professionals and other stakeholders involved in the implementation of PADDS interventions to gain a better understating of the role of the PADDS system within the complex intervention.
1.4 Expected benefits
The PADDS system is expected to facilitate distributed sense-making and decision making of the MDT with regard to the recognition, assessment and management of pain in a patient with dementia. This includes:
Assisting with individuals’ initial ‘noticing and bracketing’ of pain cues (i.e. identification that there may be pain) – including creating opportunities for noticing, and for patients communication of the patient’s pain, with carers’ contribution whenever possible.
Assisting in the making sense of the information to identify that it may be pain, the type of pain and how it manifests, within the ‘building of a picture’ of a patient’s pain – sense-making is both an individual and group activity and it happens over time.
Assisting with decision taking and actions (pain management), in a dynamic fashion that supports the empirical (trial) nature of pain management, over time, distributed across individuals.
Direct and immediate beneficial outcomes from the use of the PADDS systems are expected to be:
Improved documentation of pain assessment. This includes, for example, documentation of absence of pain as well as presence, and whether the assessment is based on clinician’s inference from a patient behaviour or from patients’ verbal reports.
Improved documentation of the trial of therapy. This includes, information on effectiveness of the trial (e.g. patient is feeling better); performance of the trial (e.g. drug was administered at a given time); outcome of trial (e.g. strategy abandoned, change in prescription); personalisation of the pain management (i.e. what helps the individual with their pain). The trial can include other forms of intervention than medicines.
Improved shared understanding of the patient pain and the best ways to manage it.
Overall, these outcomes are believed to contribute to better, patient-centred, care and improvement in the management of the patient’s pain.
2. Introduction
There has long been recognition that the assessment of pain in patients with dementia in hospital is challenging and difficult to manage effectively. Challenges are linked to the subjective nature of pain as an experience, patients’ difficulties in recall and interpretation of pain, behavioural signs of pain being altered in unexpected ways in patients with dementia, and barriers in communication. The context of hospital wards contributes to further complexity, as patients may not be well known to staff, and both the illness and the environment may create distress for the patient that adds to and confounds signs of pain. There are significant consequences related to the inadequate management of pain in hospital settings, including slower functional rehabilitation, longer hospital stays and lower quality of life, making improvements in this area of care urgent and important.
There is currently no single reliable mechanism or method that could be recommended for staff to use in hospitals for identifying and assessing pain in patients with dementia. It should be noted that recognising absence of pain is of equal importance in assessment, in order to avoid the unnecessary use of pain medications with associated side effects.
Decisions support systems (DSS) have been shown to improve care processes and patient outcomes in other clinical areas and are one of the ways in which pain assessment and management could be better supported in hospital settings. Traditionally DSS provide guidance on the basis of data about the patient and pre-set rules or algorithms, such as ‘cut-off’ points for generating alerts. In pain assessment and management of patients who are able to verbalise their pain, the patient pain intensity scores may be used, for example, to trigger an increased or reduced use of analgesics.
In the case of the assessment and management of pain in patients with dementia in hospital settings, given the inherent uncertainties about their pain and the limited staff knowledge of the patient, decision support systems cannot be based on standardised pre-set automated algorithms on the basis of inferred data points. Instead, the system needs to support HCPs judgements (recognition/assessments of pain) and decisions (management strategies) through:
The progressive, cumulative building of a ‘picture of pain’ that is specific for that patient that staff can use to ‘make sense’ of the patient’s signs as signs of pain (or not pain). This involves the meaningful display of an aggregated summary of all pain-related information gathered at different points in time by the different HCPs and HCAs involved in the care of the patient, through graphical displays that support individuals’ cognitive processes of pattern recognition.
Providing a reminder of the options for pain management that are inclusive of non-pharmacological interventions.
Providing a set of alerts on the basis of trends and unusual signs rather than activated by single individual data points.
This is what we call the PADDS system. In the following sections we first describe brief use cases for this system, to identify users, other systems, and activities involved with the PADDS; we then present what is required in the design of the system, for the system to work as intended (functional requirements specifications). Evidence and rationales in support of each of the requirements listed is provided in the appendix. Further information about the underlying rationale for PADDS is available in the documents listed at the front of this document (see ).
The PADDS system technical specifications: related documents
PADDS is recommended for use with patients with dementia, but may be used with all patients, especially those with communication difficulties.
PADDS is recommended for use with patients with or without identified pain or established presence of pain, as a reminder at any point in time that patient’s signs ‘could be pain’.
3. Use and interconnections with other systems
The PADDS system will be used in two modalities:
PADDS will be used for the care of individual patients, to support recognition, assessment and management of their pain. This includes the identification of patient specific pain cues, the establishment of pain intensity scores for EWS systems, the assessment of the presence, causes, quality and intensity of pain, the decisions about analgesics or other pharmacological or non-pharmacological pain management strategies, the assessment of the effectiveness of these strategies.
PADDS will be used for the management of activities pertaining to all patients present in the ward at a given time for which PADDS is used; PADDS will work as a system HCPs can use to monitor the quality of care for these patients. In prioritising the implementation of systems requirements, those pertaining to this second modality can be considered optional.
PADDS is an electronic system embedded and interconnected with existing hospital EPR and ePrescribing/EPMA systems. It is envisaged that most of the data displayed in PADDS will be entered through other systems in use for the care of the patient. These include: ePrescribing/EPMA systems for prescription and administration of pharmaceutical pain management strategies; EWS systems for periodic observations of a patient’s pain; clinical notes for observation and assessment of patients’ that may involve signs of pain such as specialist nurse assessments, physiotherapists’ notes, medical rounds. Should any of these systems be paper-based at the time of implementation of PADDS in the hospital wards, there should be temporary arrangements for data to be copied from these paper charts to PADDS in near real-time. However, it is an essential requirement that data entry in PADDS is not proposed to HCPs as a documenting task in addition to existing practices of documentation to be continued in parallel; rather PADDS should replace or augment existing documentation tasks.
PADDS can be used together with ePrescribing systems by displaying the interconnection between the prescription (by doctors), the administration of the medicine (by nurses) and the patient’s response to it (as assessed by HCPs or HCAs). Developers of ePrescribing systems may want to consider the possibility of alerts generated through data available in PADDS appearing in the ePrescribing system at the time analgesics are prescribed. As this pertains to the design of the ePrescribing systems, further details on this are outside the scope of this document.
It is assumed that access to PADDS will be controlled in the same way that access to other hospital systems is controlled (e.g. with NHS Smartcards, username and password combinations). Access to PADDS should be granted through these information governance/access systems to all HCPs and HCAs who care for the patient. It is also assumed that actions performed within the system will be auditable.
Relevant information about the patient’s pain provided by family members/informal carers (‘carers’) MUST be included in PADDS. However, it is not envisaged at this stage that carers, nor patients, will have direct access to PADDS. The possibility of patient/carer access to PADDS SHOULD be explored as a further development of the PADDS system at a later stage, as a new release or system update.
It is assumed that the PADDS screen will display all the necessary demographic information about the patient as per all other hospital systems and that this information will be obtained via interfacing with other clinical or PAS systems. The specification for these remains outside the scope of this document.
and illustrate the expected direct users of the system together with their goals in using this system, and the interconnections with other systems.
The PADDS technical specifications: use cases (modality 1). IT, information technology.
The PADDS technical specifications: use cases (modality 2). IT, information technology.
Note: These diagrams present a simplified generic range of users of PADDS and its connected systems identified through generic professional roles (e.g. nurses, doctors). A sample of possible interconnected systems are shown in boxes. Text displayed in ovals presents the main purposes for use of these systems. All these are not intended to be comprehensive; they need to be interpreted in the light of specifics staff roles and systems in use in each hospital context. Uses and use as represented in the diagram are not sequential (as in a workflow) but can happen in any order at any time of the patient stay in hospital. The dotted line for carers’ input to the system indicates carers’ access to the system should be granted – though this may be done on a subsequent version of the system.
4. Requirements
Each of the requirements listed below has a priority level assigned to it. Throughout this document, the following apply:
Requirements containing the word MUST are mandatory; the PADDS system cannot be expected to work as intended if they are not implemented. Delivery priority: 1
Requirements containing the word SHOULD are recommended; the PADDS system can begin to be put into use without them, while possibly implemented at a later stage. Delivery priority: 2
Requirements containing the word MAY are intended as optional. Delivery priority: 3
4.1 Usability and safety
Detailed usability and safety requirements are left outside of the scope of this document. However, it is assumed that they will be part of system design and implementation. The following are a reminder that these aspects of system design and implementation are a priority. It is assumed that the system MUST be:
safe
secure
accessible – both in terms of location and access to hardware
flexible
intuitive
fast
Assessment for usability and safety MUST be carried out prior to system roll-out.
4.2 Functional requirements
The following requirements pertain to the recording and display within PADDS of information regarding single patient records for the current admission (as per use case/modality 1 described in section 3).
The PADDS system technical specifications: functional requirements
The following requirements pertain to the recording and display of information regarding all (or a subset of) patient records available within the PADDS system at any one time in a given clinical area (as per use case/modality 2 described in section 3).
TABLE 18
The PADDS system technical specifications: recording and display of information
View in own window
| Ref. | Description | Priority |
|---|
| FR.w.01 | The user MAY be able to access a summary overview of all patients for which PADDS is active | 3 |
| This MAY be done by filtering for specific clinical areas (e.g. specific hospital wards) |
| FR.w.02 | The overview MAY display a row of summary data pertaining to PADDS for each of the patients | 3 |
| This MUST include patient identifiers (e.g. name/bed number/NHS number) |
Information MAY include:
An assessment generated by the system of how much information is available in each patient record available on PADDS
Whether important information is missing in PADDS
Whether the patient’s pain intensity scores suggest an increasing trend
Whether PADDS contain alerts or reminders that need to be addressed
The date/time of the last pain assessment
Some of this information may be conveyed, for example, by the presence of different alerting icons |
| FR.w.03 | It MAY be possible for the user to generate customised alerts pertaining to the entire set of patients, or subsets | 3 |
| FR.w.04 | PADDS may transmit some of this summary information to hospital whiteboards, as and when required | 3 |
5. Hypotheses and rationales for system design
provides a summary of the supporting evidence and rationales associated with each of the requirements listed in this document. These rationales may serve as hypotheses to be verified with the evaluation of the PADDS system.
The PADDS system technical specifications: evidence and rationales
