Specification of core requirements for clinical information systems
Specification of core requirements for clinical information systems
in support of gastroenterology
(Expanded version)
1 Introduction
This document has been developed by the British Society of Gastroenterology Information Working Party, in consultation with interested colleagues working in gastroenterology in the United Kingdom. The purpose is to define the minimum functionality of a secondary care clinical information system in support of gastroenterology.
The principles underlying the requirements specified are:
|
1.1 |
To ensure that all health care professionals working in gastroenterological practice have access to the relevant clinical information necessary to support patients under their care.
|
|
1.2 |
To provide health care professionals with on-line access to up-to-date guidance and evidence on effective treatment, both local and national, and to the information required to evaluate the effectiveness of their work; and to support professional education, development, research and the planning of services.
|
|
1.3 |
To provide the basis for uniformity of clinical systems in support of gastroenterology across the UK, so that information on activity and quality will be comparable and assist in the maintenance of the highest possible standards of gastroenterological practice.
|
The requirements specified are in line with the spirit and detail of the information strategies for England and Wales (Information for Health: an Information Strategy for the Modern NHS 1998-2005, NHS Executive, Leeds 1998; Better Information Better Health, National Assembly for Wales, 1999, and Building the Information Core: Implementing the NHS Plan, DoH, London 2001).
2 Method used
The requirements are set out as an ‘output specification’. Output specifications represent the recognised current methodology for expression of information needs within the NHS. The approach allows a non-technical definition of requirements, which enables clinicians and other users to define these needs themselves. Output specifications thus provide a way of defining a service, without the need to define how this service should be provided. This approach provides considerable advantages over the traditional method of procuring information systems in the NHS, which has been to prepare a detailed statement of need. This has often resulted in inflexible system installation, which is already out of date by the time it goes live and rapidly fails to meet the needs of clinicians. Developmental changes then become expensive. The output specification approach allows users to define the minimum requirements for the functionality of the system, leaving the detail up to the suppliers who provide the finished product. This approach requires careful work to clarify and identify what the system should do and its expected benefits, as well as the minimum standards to which it should operate.
Two important points should be noted:
|
2.1 |
The specification which follows is the minimum required to support a service in gastroenterology and should be used as a backbone for local developments, with local requirements added as necessary.
|
|
2.2 |
This specification is for a ‘system’ which will deliver many functions, some of which will be provided by integration with other components of a hospital’s overall information system. It is not intended to suggest that these should be duplicated in a purpose built departmental system.
|
Feedback on the specification, with any suggestions for change, would be welcome. The comments should be e-mailed to bsgfeedback@pgms.wales.nhs.uk
3 Specification of requirements for gastroenterology
3.1 Fundamental principles
The system shall:
|
3.1.1 |
cover all aspects of multidisciplinary and multiprofessional gastroenterological care, including inpatient, outpatient, day case, ward attendances and telephone contacts. |
|
|
Systems should enable professionals to capture details of all contacts with patients, whatever the professional or support staff involved and whatever the medium. The system should also enable capture of informal and formal discussions between professionals, whether this be on a multidisciplinary team basis or over the telephone.
|
|
3.1.2 |
enable the development of a detailed longitudinal picture of the patient’s clinical progress throughout the period of care. |
|
|
Systems should enable clinical data to be linked over time so that diagnoses are not duplicated in each contact, and the evolution of a diagnosis can be documented. Systems should also enable the capture and linkage of changes in clinical state, such as symptoms, signs and questionnaire scores.
|
|
3.1.3 |
allow attributable data collection by all professionals involved in the care of patients, including senior and junior doctors and dentists, nurses, all clinical professions, secretarial, clerical staff and, where appropriate, social workers. |
|
|
Systems should incorporate audit trails. They should also enable the individual with overall responsibility of a patient to be identified, as well as those responsible for decisions taken and actions performed for the data entry itself.
|
|
3.1.4 |
interface with other Trust information systems to enable some processes, as well as seamless access of data, and to minimise duplicate data entry. |
|
|
Systems which may need to be interfaced would include patient administration systems; departmental systems such as X-ray and Pathology; and other clinical systems.
|
|
3.1.5 |
conform to national standards recommended by the Department of Health or professional bodies, including those for a common clinical terminology and headings for communication from the record. |
|
|
Relevant standards may include those for clinical language and terminology, headings, coding, datasets and technical specifications.
|
|
3.1.6 |
Conform to the minimum standard terminology for endoscopy, as developed by the OMED and modified by the British Society of Gastroenterology. |
|
|
If the minimum standard terminology for endoscopy is appropriately coded in SNOMED-CT and this is mandated for use in the service this should be incorporated..
|
|
3.1.7 |
be sufficiently flexible to allow and support organisational change and the development of new clinical processes and services, including new methods of service provision, investigation or treatment. |
|
|
Systems should enable local customisation to incorporate changes in personnel or organisational structure, and should also build in customisable time windows so that it would be impossible to attribute data to non-existent organisations or individuals who no longer work in the organisation.
|
|
3.1.8 |
enable the electronic transmission and receipt of information between primary, secondary and community health care and, where appropriate, social care organisations, with appropriate safeguards for confidentiality. |
|
|
Systems should be able to communicate between Trusts, between secondary and primary care, and with social care organisations, with the appropriate safeguards to ensure confidentiality and security.
|
|
3.1.9 |
enable health care professionals to have on-line access to the knowledge base of health care, at the point of care. |
|
|
Health care professionals should be able to access the National Electronic Library of Health, Cochrane database, and other literature sources in the context of the consultation or other contact with patients.
|
|
3.1.10 |
enable monitoring of the training experience of junior clinicians, and inform the appraisal of all staff with responsibility for the care of patients. |
|
|
The attribution of activity to all staff should enable the monitoring of the exposure of those in training to cases, procedures and problems, and should enable review of the outcome of care in those cases where they have been involved.
|
|
3.1.11 |
provide information specifically for management purposes, including monitoring of activity and quality, as a by-product of the operational system. |
|
|
Collection of clinical, demographic and administrative data in structured form should allow aggregation, so that activity, processes and outcomes can be monitored and related to changes over time, and to personnel and the organisation.
|
|
3.1.12 |
support local and national research initiatives. |
|
|
The system should conform to nationally agreed standards, so that data can be extracted to contribute to local and national research studies on incidence and outcome of diseases and procedures.
|
|
3.1.13 |
provide on-line help for new and experienced users. |
|
|
On-line help should be available for all users in an easily accessible and comprehensive form. Help should be accessible on-line and in a form that is appropriate to both new and experienced users. The latter should be able to access the full functionality of the system with on-line help.
|
|
3.1.14 |
be supported by full documentation. |
|
|
The whole documentation of the system should also be available in paper and electronic form. This should provide sufficient information for local IM&T departments to be able to provide technological support. Help should also be available in paper form, which explains the principles of the system design, as well as providing user support.
|
|
3.1.15 |
be supported by comprehensive training for users. |
|
|
System implementation must be underpinned by comprehensive training for all users and should include training of local trainers to enable continuous delivery of training to further new and existing users. Training should be provided when the system is implemented and there should be skills transfer so that new users receive equivalent training throughout the life of the system.
|
|
3.1.16 |
be available 24 hours a day, 365 days a year. An appropriate disaster recovery plan will be required to back up normal service provision |
|
|
The system should incorporate sufficient back-up technology that down-time is effectively eliminated. Back-up facilities should be such that down-time is negligible. Back-up procedures should be such that there is no risk of irretrievable loss of data.
|
|
3.1.17 |
comply with current legislation regarding confidentiality and security, and be sufficiently flexible to incorporate future changes. |
|
|
The system should incorporate fire-walls, audit trails, access safeguards and barriers which enable organisations and users to ensure that current legislation regarding patient confidentiality and security is complied with.
|
3.2 Data capture
The system shall:
|
3.2.1 |
provide a rapid and user-friendly method of data input, appropriate to the context in which the system is used. |
|
|
The system should be usable in a wide variety of contexts, including conventional face-to-face consultations, as well as for the post-hoc documentation of telephone discussions, multidisciplinary team decisions and other issues of relevance to individual patient management. The system may be used directly by health care professionals or indirectly by clerical staff.
|
|
3.2.2 |
provide a mix of structured and free-text data collection, including the ability to add free text annotations to predefined images or drawings. |
|
|
The system should allow the facility for structured, coded data capture, as well as unstructured free text. It should also allow the incorporation of user-defined images or drawings and images collected from other sources. There should be the facility to annotate such images with text, which may or may not be codable.
|
|
3.2.3 |
enable clinical data to be organised under nationally or locally determined headings |
|
|
Users should be able to define the headings under which data are collected.
|
|
3.2.4 |
enable selected data items to be flagged for specific purposes (eg clinical importance, research etc). |
|
|
It should be possible to mark individual data items so that they can be extracted for specific purposes.
|
|
3.2.5 |
enable on-line validation of all structured, coded data. |
|
|
Users should be able to check the accuracy of all structured data collected by review of the coded term against the user term.
|
|
3.2.6 |
allow access to such coding tables as may be nationally recommended at the time and provide automated facility to code clinical data at the point of care. |
|
|
The system should be sufficiently flexible for structured data collection to use any coding system. Systems should not be built around a single classification that cannot be changed in the future.
|
|
3.2.7 |
enable the use of temporary codes for structured data collection where nationally agreed codes are not available. |
|
|
It should be possible for local codes to be assigned to enable new terms to be captured in structured format but the system should also enable these to be logged so that appropriate changes are made when national codes are assigned.
|
|
3.2.8 |
employ methods to simplify structured data collection such as pick-lists, short lists and precoded templates. |
|
|
Users should be able to generate their own short lists of frequently entered items in a variety of easily accessible forms.
|
|
3.2.9 |
enable mandation of appropriate data fields to conform with minimum data requirements for central purposes, as identified by professional and statutory bodies. |
|
|
Mandation of data fields should be set locally so that data collection for specific purposes can be ensured but changed as requirements alter.
|
|
3.2.10 |
enable flexibility of the specification of data to be collected, to allow for evolution and development over time and continuing conformance with national requirements. |
|
|
Mandation of data fields should be set locally so that data collection for specific purposes can be ensured but changed as requirements alter.
|
|
3.2.11 |
allow all users to be appropriately identified and their access to the system to be governed by appropriate safeguards, including time windows. |
|
|
The system must be potentially accessible and usable by all health professionals, who must be identifiable and only use the system with controlled and appropriate access. It must be possible to set the date and time windows for which a user could have read and write access.
|
|
3.2.12 |
enable visualisation of images (eg X-ray, pathology and endoscopy) with the patient record, and incorporation into reports and summaries. |
|
|
It must be possible for users to view images held on other systems and to incorporate these into reports and summaries as necessary. It should not be necessary for images to be held within a local system if remote viewing is possible.
|
|
3.2.13 |
enable the download of monitoring information (e.g. BP, pulse oximetry) into the patient record. |
|
|
It must be possible for certain monitoring data, held in digital form, to be incorporated into the record if users require this.
|
|
3.2.14 |
enable capture of data on equipment use. |
|
|
It must be possible for the use of equipment for certain procedures to be recorded, so that this can be analysed and reviewed retrospectively. It must be possible to link equipment to individual patients and to operators.
|
|
3.2.15 |
enable capture of data on complications, both clinical and technical, during and after investigations and procedures. |
|
|
The system must allow clinical data captured after an investigation or procedure to be linked to that action, if appropriate.
|
|
3.2.16 |
enable capture of multi-item measures (such as quality of life, activities of daily living, and severity measures) and automatic score calculation. The system should allow local configuration of such measures as required. |
|
|
The system must allow local incorporation of multi-item measures, with automatic coding of the constituent items and automatic calculation of scores. It must be possible to link such recordings over time, so that outcome can be monitored.
|
|
3.2.17 |
enable capture of technical data in appropriate clinical context, such as radiotherapy, endoscopic and physiological monitoring procedures, and other interventions. |
|
|
The system must enable linkage to systems, which record in detail the technical component of diagnostic and therapeutic procedures, so that these data can be accessed by users.
|
3.3 Process support
The system shall:
|
3.3.1 |
support on-line ordering of tests and investigations. |
|
|
Users should be able to order laboratory and radiological tests on-line, at the point of patient care. Clinical details associated with requests should be automatically derived from that held within the system.
|
|
3.3.2 |
support on-line prescription and administration of medication. |
|
|
Users should be enabled to prescribe on-line and the system should record the full details of administration of medication.
|
|
3.3.3 |
enable access to an appropriate scheduling system for all patients using the service. |
|
|
Users should be able to book appointments for investigations and procedures at the point of patient care. The system should be configurable so that this facility is available to patients in due course.
|
|
3.3.4 |
enable scheduling to include resources such rooms and equipment. |
|
|
The scheduling system should include booking of rooms and equipment, and ensure that duplicate use of resources such as rooms and equipment does not occur, and that the use of these is monitored.
|
|
3.3.5 |
enable direct communication between professionals within and external to the organisation. |
|
|
The system must incorporate the facility for electronic communication between professionals, without breaching patient security.
|
|
3.3.6 |
Enable direct communication with suppliers of goods and services. |
|
|
External communication should include the ability to communicate with suppliers of goods and services so that as resources are depleted reordering is facilitated
|
3.4 Data retrieval
The system shall:
|
3.4.1 |
be secure and confidential, and only accessible on a need-to-know basis to authorised users. |
|
|
Local customisation must include the ability to set up individual users with access as appropriate to need.
|
|
3.4.2 |
produce an audit trail of user access to data. |
|
|
Both read and write access must be monitored within the system.
|
|
3.4.3 |
provide efficient and speedy retrieval of data by appropriate personnel. |
|
|
Users must be able to retrieve data appropriate to their need, both on individual patients and in aggregate form.
|
|
3.4.4 |
produce individual patient summaries and reports, the format of which can be defined by users. |
|
|
Individual patient summaries should be customisable at a local level.
|
|
3.4.5 |
enable summaries and reports to be transmitted to other systems (including primary care) as an appropriate mix of free-text and coded data. |
|
|
Electronic linkage to other systems within and without the organisation must facilitate the transmission of free-text and coded data.
|
|
3.4.6 |
provide the ability to produce ad hoc reports without the need for specialist technical ability. |
|
|
Users must be able to set up their own analysis of the data held on the system, without the need for recourse to specialist help.
|
|
3.4.7 |
enable users to schedule reports, where appropriate. |
|
|
The system should generate reports automatically for defined purposes.
|
|
3.4.8 |
provide an ability to customise data reports to support differing information needs of professionals and elements of the service. |
|
|
A suite of reports should be developed for users but it must be possible to change these as requirements develop.
|
|
3.4.9 |
enable the analysis of aggregate data for monitoring of quality (including outcomes), planning new services, supporting research activity, and the monitoring of training. This will require the ability to analyse by clinical headings and coded terms, patient demographics, staff, organisation, episode, location and referral source. |
|
|
The system must incorporate a comprehensive analysis and presentation facility so that comprehensive interrogation is possible by suitably trained local staff.
|
|
3.4.10 |
enable the production of longitudinal views of the patient’s progress, including changes in health characteristics such as symptoms, signs and diagnosis (and their severity where appropriate), and the progress of laboratory tests over time. |
|
|
Outputs must include the ability to produce a sequential picture of a patient’s progress, including all contacts with different professionals and linkage of diagnoses, symptoms, multi-item scores and test results over time.
|
|
3.4.11 |
provide the facility for graphical representation of data. |
|
|
Graphical presentation software must be included so that users can present their data in appropriate graphical form.
|
|
3.4.12 |
enable monitoring of patient distribution in the hospital. |
|
|
Users must be able to identify the location of individual patients within the hospital and generate aggregate reports of all patients according to healthcare professional who is responsible for their management, diagnoses, procedures and other clinical data.
|
|
3.4.13 |
enable monitoring of waiting lists and waiting times. |
|
|
Users must be able to monitor the number of patients on a waiting list for consultation or procedure and the times that patients are waiting. They should also be able to link these data to diagnoses and symptoms.
|
|
3.4.14 |
enable access to results of investigations and tests undertaken within the Trust, in both structured and free-text form. |
|
|
Users must be able to access numerical and free-text investigation results.
|
|
3.4.15 |
allow the export of raw data in the event of system failure. |
|
|
It must not be possible for data to be lost if the system fails.
|
3.5 Remote access to information
The system shall:
|
3.5.1 |
enable access to information about individual patients held on other systems both within and external to the Trust. |
|
|
The system must enable users to interrogate an individual patient’s electronic health record with appropriate confidentiality safeguards. Within the Trust there must be inter-communication between clinical and administrative systems.
|
|
3.5.2 |
enable remote access to research papers, reviews, guidelines and protocols. |
|
|
Health professionals must be able to access the knowledge base of health care at the point of contact with patients.
|