IT and data

Essential elements and recommended practice for screening IT systems, data collection and reporting.

Nationally managed and delivered screening programmes require the management of large numbers of people through multiple steps of a screening pathway which may cross geographical and health service boundaries. The ability of a screening programme to reduce ill health relies on maximising the number of people who engage with screening and follow the pathways. This is not an activity which can be safely managed using manual processes; it requires the use of information technology (IT) systems.

A programme-wide screening IT system is needed to:

  • identify the cohort to be invited
  • facilitate the management of each person through the entire screening pathway
  • ensure a link to outcomes

Such a system is necessary to ensure:

  • the entire eligible cohort is invited
  • each person (who wishes to engage) is followed up
  • individuals and their health service provider are reminded of the next step in the pathway (highlighting if they missed something, or need a reminder, or a repeat test/offer of an appointment)

A screening IT system supports adherence to standards and the monitoring of processes critical to the completeness of the programme and to activities that drive the effectiveness, safety and acceptability of the programme. A screening IT system that is managed and updated centrally removes the risk of local system variation, ensuring uniformity of data collection and reporting across providers, and allowing effective quality assurance of services.

When designing or implementing a screening management system, the elements described below should be considered.

General principles

A screening IT system may not always be delivered by a single application or software package. Multiple components may be needed to fulfil programme requirements, for example function-specific applications to deliver cohort identification, image management or communication tasks. However, from a user’s perspective, these components should operate as a single system, with complexity masked by a standard system-wide interface. Users should not be required to access multiple systems or use multiple logins to deliver the various elements of a screening programme. The system should:

  • be able to support all aspects of the screening programme, both clinical and administrative
  • act as a single repository of information
  • provide access to all relevant screening staff

The system should be designed according to an output-based specification that is defined in terms of the needs of the screening programme and aligned with its pathways and processes. The specification does not need to be prescriptive in terms of how the requirements will be achieved. But it must clearly define what those requirements are and how people should move between them, together with the expected actions and outcomes to be managed at each stage. The specification must be developed with input from relevant subject matter experts (SMEs) including clinicians, other relevant healthcare professionals, experts in screening policy, quality assurance, programme management, clinical systems, administration, data analysis and reporting.

No system or specification is future-proof and screening programmes evolve over time. In addition to aligning with current processes and standards, it is essential that a programme-wide IT system is flexible enough to support emerging innovation and policies and reflect changes to national guidance. Examples could include revised criteria for eligibility or referral, new reporting requirements, or changes to screening intervals. Following initial implementation, a process of continual development should be established to make sure the system is regularly updated based on user feedback and continues to meet the needs of the screening programme.

Screening is only one aspect of healthcare and it is important that a screening IT system can establish secure links with other aspects of care, for example:

  • the first point of access into a health care system (primary care systems)
  • the medical care provided by specialists (secondary care systems)
  • national registries (disease or treatment specific databases)
  • other databases

These interfaces may be used for cohort identification, onward referral, results notification or failsafe purposes, for example linking to a treatment database to monitor outcomes and ensure that referrals are acted on in a timely manner. Wherever possible, any exchange of information between the screening programme and external services should be delivered by electronic means rather than manual processes. The ongoing development and review of a screening IT system should include consideration of the impact on these interfaces and the potential for establishing new or enhanced links with other national healthcare systems.

Screening does not always take place in a hospital or clinical setting and a reliable network connection may not be available at the point of screening. Screening IT systems should therefore support access from a variety of settings using an offline client (locally installed standalone version of the screening software) in addition to a live networked client or web-based application. The system must be able to synchronise information captured and stored on the offline client with information held on the live system database once a network connection is available.

Regardless of the complexity of the underlying IT system, the interface should be user friendly and intuitive to operate. System use should not significantly add to a clinician’s or administrator’s workload. The system must be acceptable to users and improve the efficiency of processes, not increase their burden. System guidance documentation and training opportunities must be available to support users in the successful operation of the system.

Consideration should be given to the ongoing management and support of the screening IT system within the context of a national or large-scale screening programme. SMEs in data analysis and IT management will be required, and system user groups should be established to offer peer support, shared learning and provide feedback on the system to identify any development gaps or opportunities. There should be agreed change and release management processes for the approval and implementation of updates to the system, and appropriate system support services such as a user-accessible helpdesk. It is important that functions critical to the successful operation of the IT system or the screening programme, such as data extraction, do not depend on a single individual and are protected by appropriately clear and binding, contractual arrangements.

Security and information governance

Screening IT systems routinely process large amounts of personal and confidential information. The protection of such information is vital, so security of these systems is paramount. Systems must be compliant with relevant national and international legislation on data security, such as the General Data Protection Regulation (GDPR) and Network and Information Systems (NIS) Directive in Europe, or the Health Insurance Portability and Accountability Act (HIPAA) in the US. In England, systems are managed in accordance with the NHS Information Security Policy and DHSC Data Security and Protection Requirements. A Data Protection Impact Assessment must be conducted and signed off by the organisation’s data protection officer or other relevant individual before system use begins. The sourcing and sharing of any data used for cohort identification and maintenance must meet the requirements of the relevant national legislation on data sharing. Legislation will determine whether an individual’s express consent is also required. Where applicable, a data sharing agreement should be put in place between the organisations providing and receiving the information.

In the UK, the Data Security and Protection Toolkit (DSPT) provides a mechanism by which a screening programme and its IT suppliers can demonstrate compliance with the National Data Guardian’s Data Security Standards. Equivalent self-assessment tools should be used where they exist. The system must be capable of exporting a person’s record in a suitable format in response to a data subject access request, in line with the UK Data Protection Act 2018 or equivalent national legislation. The system should support a consent/opt-out model for the use of personal confidential data, such as the National Data Opt-out in the UK. It should be capable of recording an individual’s consent status regarding the use of their personal information, ensuring that data is not shared for research or planning purposes where consent has been withdrawn. Functionality for the archiving and secure deletion of personal data must be available in order to comply with applicable schedules on the retention of health records.

Access to the screening IT system should be via secure login with appropriate authentication. Access should only be granted to those with a genuine and confirmed need. Measures should be taken to make sure the system is not accessed using unsupported operating systems or web browsers. The system should have in-built access controls which limit users to those parts of the system applicable to their role, and to details of people whose care they are involved in, or for whom they have a legitimate reason for viewing the record.

A screening programme relies heavily on its IT system always being operational. Safeguards must be in place to minimise downtime of the system and prevent loss of data. Automated system backups should take place on a frequent and regular basis (ideally daily), with the ability to restore backup data quickly and safely as part of a disaster recovery plan. A separate server housing a copy of the live system should be employed to test functionality, train users and conduct acceptance testing of each new release in order to minimise the risk of accidental harm to the live system data as a result of these activities. All servers used by the screening IT system, whether live, backup or test, should be housed in secure data rooms.

Audit capability

The screening IT system must be able to provide a complete audit trail of activity relating to people’s screening records. It is important that every instance of access to personal data on the system can be attributed to an individual user, so that appropriately authorised individuals can easily identify which users have viewed or amended a record, and when this occurred. A record should be maintained within the system of all communications with a person, or with another healthcare professional regarding that person’s care.

Where information flows into or out of the screening management system via interfaces with other IT systems, this should be auditable, for example by capturing and storing the transmission status information for each message received and sent. Changes made to people’s records as a result of these information flows must form part of the audit trail for that individual.

Interoperability

Screening IT systems must be able to exchange information with other healthcare systems electronically in order to support the provision of care. All such interfaces should meet appropriate national or international standards such as the Health Level 7 (HL7) framework or current equivalent, which provides a set of international standards for the transfer of clinical and administrative data between software applications used by healthcare providers. Fast Healthcare Interoperability Resources (FHIR) or current equivalent should be used for the development of any application programming interfaces (APIs) which connect the screening IT system with other healthcare systems.

Messaging systems which send personal data must log message transmissions and, where possible, should provide notification of the receipt of that message by the recipient. Data should be transferred and received in real time.

Cohort identification and maintenance

For any screening programme to be effective, it is vital to correctly identify the eligible population and keep everyone’s details up to date. The screening IT system must facilitate this.

In most cases, accurate cohort identification and maintenance will require an interface with one or more suitable source systems holding the data necessary for identification of eligible people and providing the personal information required to invite that individual for screening.

The screening management system must be capable of creating new records and updating current records based on information received from the source system. System checks should be in place to assure the quality of data being received, with the ability to reject records which do not meet the stated criteria. A log of such rejected records must be retained.

A national unique identifier must be stored for each person. In the UK, for example, this is a validated NHS number. This should be used as the unique identifier for receiving, updating and sharing information. The data received for each person must include the minimum information required in order to invite them for screening. Where possible this should include data on protected characteristics so the screening programme can address health inequalities and make reasonable adjustments for an individual where necessary. Consideration should be given to the identification and management of underserved or transient populations and the collection of data for people in these groups. Examples might include:

  • people in secure settings and other residential facilities
  • people from Gypsy, Roma and Traveller populations
  • military personnel
  • people transferring across borders between different providers or nations
  • people who are not on population registers

Identification of newly eligible people should be carried out according to a schedule appropriate for the screening programme. This may be done annually, monthly, weekly or daily. Demographic updates for the existing cohort should be received as frequently as possible, ideally daily or in real time. This is to minimise the risk of invitations being sent to incorrect addresses or to deceased or ineligible people. The screening IT system must include a mechanism for automatically requesting the ceasing of electronic updates for people who have completed the screening pathway or become ineligible for any reason.

The screening IT system should be able to automatically associate each person with their appropriate local or regional screening provider according to set criteria, for example postcode or registered primary care practice. Each person’s record should be accessible only by that local provider and those involved in the person’s care or with a legitimate need to view the record. Functionality must exist to allow this association and access to be updated within the system if the person’s circumstances change and they become the responsibility of a different provider.

In addition to this automatic creation of records based on information provided by an interface with a source system, providers must also be able to add people manually to the system. For example, this can be for self-referrals or those referred to the screening programme via another route.

Invitation management

The screening IT system must provide all functionality required for the issuing of invitations and booking of appointments. The system must be able to identify which people are due to be screened and to make this information readily available to the user, allowing timely invitations to be issued. Due to the scale of most screening programmes, bulk generation of standard invitation letters must be available from within the system, and SMS text reminders or equivalent functionality should be incorporated where possible. Auto-booking of appointments by the system may be considered for less complex cohorts. The system should be able to send letters directly to a local or networked printer as well as generate letters in a format suitable for transfer to an external print or mail provider. Where invitations are issued via email, this functionality should be incorporated directly into the system to ensure appropriate tracking and reporting of invitations.

The system should be able to issue invitations in a format which meets the communication needs of the recipient, for example in a different language or in easy read format. Where possible, this should be triggered automatically based on relevant information recorded within the system.

The system should allow for flexibility in terms of invitation model, as necessitated by local variations in operational delivery, geographic constraints or national directives. Invitation models include:

  • ‘open’, where the person is asked to contact the screening service to make an appointment which is convenient to them
  • ‘partial’, where the person is provided with a choice of dates, times and/or locations and asked to select the most convenient
  • ‘fixed’, where the person is provided with a set date, time and location which they do not have to confirm (but can request to be changed if not convenient)

It may be necessary for the system to support a combination of 2 or more invitation models according to local need, and for this to be configurable by users with appropriate permissions.

Providers should consider setting up an online self-booking facility for eligible people. This may be delivered via a publicly assessable website or appropriate mobile application such as the NHS App in the UK. However, any appointment self-management functionality should be an addition to standard invitation management and appointment booking processes, not a replacement for them. Measures must be in place to ensure online self-booking functionality does not compromise the screening programme’s ability to offer timely appointments.

The screening IT system must include comprehensive administrative functionality, providing users with simple tools which allow for flexibility in clinic and appointment management. For example, this can be the ability to book variable length time slots to enable reasonable adjustments to be made for people who require them. Functionality for the management of people who do not attend (DNA), do not respond (DNR) or who decline screening must be included, and must operate according to screening programme policy. Tools to help with capacity and resource management of the screening service should be included.

Screening information

Depending on the condition(s) being screened for and the test involved, the screening management system may need to link with diagnostic or imaging equipment in order to exchange or import information and files. Tools for the assessment of images may also be required as part of the screening IT system.

Where electronic imaging is used, the transfer of information between the screening IT system and external equipment should employ the Digital Imaging and Communications in Medicine (DICOM) international standard. Where the use of DICOM is not applicable, there must be mechanisms to ensure information received from an external piece of equipment is uniquely associated with a person and can be directly imported into their screening record.

It must be possible for screening staff to record information directly on to the screening management system at the point of screening. Avoid recording information on paper or elsewhere for input onto the IT system later. The system must be able to record that each person has made an informed choice to proceed with the screening test and should prevent a user from proceeding within the system if this consent has not been recorded.

For some screening programmes it will be necessary for a picture archiving and communication system (PACS) to be incorporated into the screening management system. The PACS architecture will vary according to business need. But it should include a central image server with the ability to transmit captured images to that server, and to view images stored on it, all from within the screening IT system. To the user, it should appear that they are accessing a single piece of software which encompasses this functionality.

Screening outcome management

In order to facilitate large scale screening programmes, outcomes should be system-generated wherever possible, based on the results recorded. The system must be able to identify people who need onward referral based on set criteria. If multiple pathways are in use, for example surveillance or variable recall intervals, the system must be able to recommend or enforce the appropriate pathway.

The system should automatically generate result letters for each person according to their outcome. The system should also communicate these results to the healthcare providers responsible for the person’s care. Where possible, electronic communication of screening results to primary and secondary care providers should be adopted. In England, systems such as the Message Exchange for Social Care and Health (MESH) and National Events Management Service (NEMS) may be used for this purpose. Countries such as Sweden and Israel have implemented national health information exchange (HIE) systems. In the USA, the State HIE Cooperative Agreement Program has led to the creation of a number of state-designated health information exchanges and the expansion of existing HIEs such as the Indiana Health Information Exchange. The screening IT system should connect with such exchanges wherever they exist.

More than 40 countries worldwide use the Systematised Nomenclature of Medicine Clinical Terms (SNOMED CT) as the recommended clinical reference terminology for health information systems. Where this or an equivalent system is in place, it may be useful to specify a set of clinical terms associated with the screening programme and communicate the relevant code(s) to the person’s GP, or other responsible healthcare provider, as part of the screening result. This will help to facilitate the accurate recording of screening outcomes in primary care and elsewhere.

Referrals, whether for a diagnostic test or for intervention/treatment, should be issued electronically from within the screening management system wherever possible. This may be achieved via integration with an electronic referral service if one exists (for example the NHS e-Referral Service in England or Medcom system in Denmark), or via an interface with the healthcare management system used by the receiving service. Such interfaces should provide an acknowledgement of receipt of the referral message and a subsequent confirmation of acceptance of the person by the receiving service. The outcome of the diagnostic test or intervention should be returned to the screening management system via the same interface, wherever possible.

Where direct electronic referral is not possible, it may still be necessary for referral and outcome data to be exchanged with an external system, for example to update a national registry. Interfaces need to be available for this.

Where electronic communication methods have been established, it should remain possible for letters to be selected and printed from within the screening management system. This is to ensure timely referrals can be made and results issued in cases of external system failure, or in other situations where electronic communication is not possible.

Data and reporting

The screening IT system must be able to collect, store and report on a wide range of data items for performance monitoring, quality assurance, evaluation, effectiveness and research. A minimum dataset dictionary should be developed to clearly define the data items recorded within the system, the permissible values for each field, and whether collection is mandatory or optional. It is recommended that this information is made publicly available to support future research and provide transparency for the screening programme. Development of the screening dataset should consider any existing datasets for related services and align data items where possible.

Careful consideration should be given to reporting key performance indicators (KPIs) and other screening standards, to ensure data items required for accurate reporting are included in the system and can be uniformly collected by each local screening provider. Some data items will need the system to derive information rather than simply report a value entered by a user, for example when reporting due dates or counting invitations. It is vital that clear rules are established for how the system will derive such information.

Accessibility of the data held within the screening IT system is of great importance, both at local and national level. The system must be able to generate standard nationally defined reports for performance monitoring, effectiveness and quality assurance, and ad-hoc customised reports that allow providers to monitor specific areas of performance according to local need. Data on operational activity must be available (in real time where possible, to aid capacity planning and resource management both locally and nationally. It should be possible for the system to produce specified data outputs for research purposes, in line with each person’s recorded consent status, and in a format that can be linked with other datasets. Providers of screening programmes should be restricted to viewing only their own data in detail, and a summary of national data.

A data warehouse should be created and populated on a frequent and regular basis, and reports should be run against this rather than the live system database. This is to ensure no negative impact on system performance. Automated processes should be used as much as possible in the data warehouse to produce public facing reports from the raw data. High level indicators should be published every quarter, and screening standards should be published at appropriate intervals.

National management of the screening programme must include the use of data analysts with direct access to the data held within the screening management system via the data warehouse. Additional business intelligence software may be used for the extraction and analysis of this data, or this may be developed as part of the screening IT system. System IDs should be used in place of national identifiers, such as NHS numbers, when extracting and analysing data centrally. Access to all personally identifiable fields should be minimised. Where confidential personal information is used, there should be a clear justification for doing so, ensuring it is only accessed when necessary and is limited to the minimum amount of information required for a given function.

Future changes to local screening provider boundaries and health geography boundaries and the impact this may have on reporting should be considered. A postcode or equivalent geographic identifier should be recorded for each person, and where possible, functionality should be developed within the system to allow boundary changes to be considered when reporting over time.

Quality assurance

The screening IT system must be able to store and report on data items, standards and indicators used to quality assure screening services.

The screening IT system should include functionality to quality assure any diagnostic or clinical processes undertaken within the system, introducing checks to ensure that screening tests are being carried out to an acceptable standard and that clinical decisions are accurate. Examples could include measures to prompt the reassessment of a set proportion of screening cases or to provide systematic comparison of outcomes per screener or clinician in order to identify outliers. Such measures may involve automatic rule-based sampling of images for review, and functionality to support manual requests for reassessment. If appropriate technology exists, there may be scope for an automated analysis of image quality or positioning within the screening IT system, allowing sub-standard clinical images to be flagged up automatically.

The outcomes of these quality assurance (QA) processes should be easily reportable and available to users with appropriate permissions. Where possible, the system should be able to provide feedback to clinicians on their own performance. Where a QA review changes a screening outcome, the system must be able to update the person’s pathway accordingly.

Functionality may be developed within the system to provide ongoing QA of workforce competencies through regular assessment of diagnostic or other clinical skills. This could be achieved via the use of a mandatory test set, e-learning resources, knowledge assessment or training support system which users need to engage with at set intervals. Such a system should be able to generate individual performance reports and provide detailed information to support the ongoing development of knowledge and skills.

Failsafe

The screening IT system must include failsafe checks to ensure the eligible population is identified and invited for the intervention and that appropriate action follows the intervention. Measures must be put in place to ensure no person can be ‘lost’ within the system or actions left incomplete, and that users are alerted to people who require attention. Automated system checks should run frequently in order to identify missing information or errors in the screening pathway. System prompts should exist to flag these to the user/s and make sure remedial action is taken.

System processes must be in place for the management of DNAs, DNRs, exclusions and opt-outs. The system should recognise when a person has not responded to an invitation within a set time period or has failed to attend an appointment. This should automatically trigger appropriate actions within the system, such as a reminder or rebooking process. The system should ensure people can only be excluded from screening in line with national policy and that such cases are auditable within the system. Comprehensive search functionality must be included to allow people to be identified according to a range of criteria.

If awaiting further information, for example an outcome following a referral, the system must be able to monitor this and prompt the system user to obtain it. Failure to record this information within a set time period should trigger an appropriate action, such as a re-referral or re-invitation for screening. Where mandatory information is entered manually by the user, for example when recording consent at the time of screening, the system should prevent the user from proceeding until all mandatory fields have been completed.

Whenever the responsibility for a person’s care is passed from the screening programme to another health provider or service, failsafe mechanisms must be put in place to confirm receipt of the referral or transfer request, and acceptance of the person by the external service. This must be recorded within the screening management system. The system should ensure that the person remains active within the screening pathway until this is received and recorded.

The role of the screening programme within the context of a wider care process, such as for diabetes or cancer care, should be considered. Electronic links with relevant national registries, databases and audits should be developed in order to exchange information, improve data quality, evaluate the effectiveness of screening services and provide additional failsafe for people under the care of the screening programme.