Demand optimisation in diagnostics: standardising diagnostic testing in NHS Boards

Appendix F - Information Technology Guidance

THE SCOTTISH NATIONAL DEMAND OPTIMISATION GROUP

IT Guidance To Support Demand Optimisation Activity

Across Diagnostic Services

Background

It has been said that the practice of modern medicine is beyond the capability of the unaided mind. This delivers challenges to those wishing to deliver maximum benefit from investment in services that enable access to a readily available and rapidly growing repertoire of diagnostic tests. Triple Aim requires that the demand on such services is optimised. There is therefore a requirement to deliver systems and processes to help facilitate demand optimisation of diagnostic services.

Demand optimisation is defined as the process by which diagnostic test use is optimised to maximise appropriate test requesting which, in turn, optimises clinical care and drives more efficient and effective use of scarce resource and consequently delivers Triple Aim. There are significant impacts to be gained by optimising demand and many tools can be employed to enable delivery. Interventions need to be focussed on not just minimising over-requesting, but also under-requesting and reducing unnecessary repeat requesting. The ability to extract diagnostic requesting behaviour data and the functionality to deliver efficient, and in some cases automated, demand optimisation interventions is largely linked to information technology ( IT) functionality that is resident within the diagnostic service environment and beyond. The following guidance focuses on defining some of the most desirable attributes that should be present or used within diagnostic IT systems to support demand optimisation activity in order to enable the collection of useful data, facilitate interoperability of diagnostic test results between systems within and between NHS Boards, and deliver demand optimisation interventions.

The guidance focuses largely on systems and concepts aligned to laboratory medicine, but the content is applicable to other diagnostic services. Separate sections on specific radiology applications are however included.

1 Diagnostic Services IT Systems

The following levels of IT operation need to be considered:

a) Laboratory Information Management Systems ( LIMS)

It is vital that each laboratory LIMS system has the necessary ability and functionality to deliver demand optimisation activity. Such functionality is rarely present as standard, however the majority of LIMS system providers are now beginning to develop specific demand optimisation modules that will assist in this process. It is therefore important that laboratory services are aware of such developments, seek to promote their use, and also try to ensure that such functionality is included within the specification of any new procurement exercise for a laboratory IT system.

b) Order Communications Requesting Systems (Order Comms)

These systems are frequently being used across NHS Boards to enhance and automate requesting and reporting of laboratory test results. Examples are Trakcare order comms and Sunquest ICE. Once again the functionality of these systems is vital with regards to the collection of useful data and the delivery of demand optimisation interventions.

c) Clinical Databases and Electronic Patient Records ( EPRs)

Many systems are in operation across the NHS including GP systems, hospital EPRs and specific disease level databases (renal, diabetes). It is vital that such systems are not only interoperable within laboratory based systems (using a common language) but are also able to accept and display any demand optimisation intervention output in a seamless fashion.

d) IT Translation Engines

Interoperability between IT systems is a challenging area within the NHS. The ability to transfer laboratory results between labs or NHS Boards remains difficult owing to the different systems being used and the different coding applied to test name, units, reference intervals and linked clinical terms. Systems have become available (bolt on software for LIMS), such as the National Pathology Exchange ( NPEx), that do enable this communication functionality. Such systems can improve the efficiency associated with send away work, reduce turnaround times and minimise transcription errors - thus improving patient safety.

e) Radiology IT systems

Radiology information flow mirrors that of labs with the Radiology Information System ( RIS) replacing LIMS. The scheme is therefore Order Comms - RIS - EPR. Provision of demand optimisation modules in RIS is variable between vendors. However there has been much success in using external statistical packages to measure referral parameters. Furthermore, standardised RIS coding for examinations has been implemented across Scotland allowing direct comparison of hospitals and boards. As with laboratory specialties, Order Comms presents an opportunity to both analyse clinician referral behaviour and to deliver contextual decision support during requesting.

Images are stored in the Picture archiving and communication system ( PACS) which is centralised to a Scottish national archive as well as peripheral board archives. It is hoped that access to national demand data directly from the Scottish National archive will be possible.

2 IT Systems Functionality

The following levels of IT functionality and activity need to be considered across all relevant IT platforms to enable demand optimisation programmes to function across diagnostics:

a) Data Collection Activity

It is vital that IT systems are put in place that will enable and enhance the ability to collect and extract data to inform, monitor and support demand optimisation activity. Functionality should be inherent within laboratory information systems ( LIMS), radiology IT systems, order communications systems (order comms), and any other clinical database used for archiving, reporting or storage of diagnostic test results. Such requesting activity data should be easily extractable and examined at Health Board, Hospital, Ward, GP Practice, and individual clinician/general practitioner levels. The relevant IT systems should be able to provide such information on a regular basis and allow chronological examination of any trends. For any data collection, it is important to reference the need for interoperability and standardisation between systems (see below). This is especially important when such data is to be accumulated on a national basis and comparisons made. The additional ability to include analysis tools within the Diagnostic IT systems should also be considered, especially at the LIMS/Radiology system level. Such functionality should allow the clear and easy identification of potential over-requesting, under-requesting, unnecessary repeat testing, and gaps in available diagnostic test repertoire.

b) Test Request Blocking

It is important that LIMS/Radiology systems and order comms systems have in-built functionality to facilitate the automated blocking of potential inappropriate test requests. Automated blocking of such requests should be an in-built function and should occur automatically when the request is made within the relevant minimum retesting intervals time window or other appropriate clinical timeframe. The blocking decision should be made based on previous requests and/or the existence of a valid test result within such a time frame. This test result should be reported again back to the requester at this time. Such blocking of inappropriate requesting should ideally be made at the point whereby a request is being initiated and ideally before a blood sample/radiology request has been taken/made. Such functionality is therefore best implemented at the order comms requesting stage, thus allowing requesting behaviour modification so as to avoid unnecessary venepuncture/sample transportation to the laboratory or equivalent within radiology. It should be acknowledged that any minimum retesting intervals guidance is not completely fool proof and therefore decisions to block requests should be made based upon local circumstances and following discussions with users. All IT systems should be able to allow bypass mechanisms to be effected if necessary.

c) Requesting Audit and Feedback

IT systems, and especially LIMS/Radiology level, should have in-built functionality that enables the reporting of specific requesting behaviour back to individual clinicians, GPs, GP Practices or Wards. Such data presentation should allow chronological trends to be identified and reported back to users. The ability to incorporate financial costs associated with requesting behaviour and the ability to adjust any figures for known confounding variables (such as GP Practice list size) should also be possible.

d) Interoperability and Standardisation

No recognised standard for laboratory test names, units of measurement, reference intervals, or associated clinical coding is available or has been implemented uniformly across all Scottish NHS Boards. This severely limits both the ability to combine data extraction and for laboratories to communicate with each other. Attempts have been made, and are still underway, to develop standardised systems such as the National Laboratory Medicine Catalogue. The development of such systems is extremely challenging and is unlikely to be available for a number of years. As such systems do become available, it is important that laboratory/radiology IT systems, which include analysers, order comms, LIMS, clinical reporting databases, and electronic patient records, are all populated with such coding if available.

The delivery of standardised data sets and data archetypes is an important concept for the immediate and longer term. It does however deliver a degree of complexity and requirement for discipline around coding and taxonomy. A pragmatic approach will be required that will lead to a planned convergence of organisations towards the use of common coding systems. This will enable a transitional phase to deliver immediate benefits in some key areas. In the longer term the advantages of commonality of coding with a supporting taxonomy will enable big data approaches within diagnostics. Historical data requires that key characteristics of the data item are stored (data archetype, including investigation type, instrument, units, standardisation used, reference data etc) to enable benefits from archived data to be realised. The managed diagnostic networks should consider this as a cross network work stream. There are internationally recognised approaches for coding including NPU, SNOMED CT, etc.

e) Laboratory to Laboratory Communication

To a greater or lesser extent, all laboratories in Scotland currently outsource a number of samples/tests to other laboratories, both within Scotland and out with. This has generally been done on a manual basis, mainly due to the limitations in system interoperability as identified above. Until such interoperability can be resolved, many laboratories have begun using the National Pathology Exchange ( NPEx) system to allow both the requesting and reporting of laboratory tests between laboratories. This effectively uses a translation engine that allows direct communication between the LIMS systems of different laboratories/ NHS Boards. The implementation of NPEx or related software applications should therefore be encouraged to allow more efficient and safer cross-boundary activity to take place.

3 Radiology Systems Functionality

It is envisaged that most radiology demand will come via ordercomms systems with the radiology information systems ( RIS) containing demand and activity data. Within Scotland there are multiple instances of these systems provided by 4 ordercomms vendors and 3 RIS vendors. It is unlikely to be viewed as cost effective to ask existing vendors to alter the current nationally installed solutions. The preferred route is a national strategy utilising external solutions. As described elsewhere in this document, demand optimisation consists of 2 major components namely measurement of demand and modification of requestor behaviour.

a. Measurement of Radiology Demand.

The Scottish Clinical Imaging Network ( SCIN) are currently working closely with NSS to implement a central data warehouse driven solution to display aggregated demand and activity figures for all Scottish Radiology departments. NSS already perform this task for a number of other clinical areas. This will allow powerful linkage of radiology data to other hospital specialties. However, individual departments need to be encouraged to formulate their own local business intelligence strategies. Using 3rd party software, SCIN have demonstrated the ease in which demand, activity and queue data can be displayed both live and retrospectively and are offering this support via SCIN. The involvement of the local health board information services department is also to be encouraged for example in the creation of local dashboards. Some departments have chosen to engage with 3rd party companies to provide data analysis services. Modification of the current installed RIS systems is not seen as a viable solution at the current time. We strongly recommend that all future RIS acquisitions include business intelligence modules as well as back end SQL data access for 3rd party data analysis. Finally, as important as the software solutions, it is necessary to have parallel protocols and processes to interpret, monitor and act on the resultant data. In particular all departments should perform breach management monitoring and capacity planning. Feeding back total demand (and total xray dose) figures to clinicians is highly desirable. Automated dashboards will facilitate this.

b. Requestor Behaviour Modification

i) Before Request - This primarily depends on clinicians adhering as closely to agreed local guidelines for the various clinical scenarios. It is strongly recommended that local clinical teams engage and agree on management pathways where possible. Radiology departments are often well placed to coordinate this activity. These guidelines need to be accessible and visible to clinicians. National Education Scotland are currently going to tender for systems to embed guidance into existing EPR applications. Whilst other forms of dissemination remain important, it is likely that this form of embedded contextual clinician decision support will prevail.

ii) During Requesting - The provision of pertinent data within order comms at the time of requesting is paramount to request quality. This includes recent results, possible duplicate request, clinical information and decision support material. The increased usage of Clinical portal and other EPR systems largely provides this information. SCIN are currently evaluating the European Society of Radiology ( ESR) iGuide system that is designed to provide immediate advice to the requestor by displaying a clinical 'appropriateness score'. This system has shown to be useful in the US and is also in use in Some European countries. The system also generates an automated audit of requests for individual clinicians. A pilot of this software is currently planned in England and Scotland. This will be in collaboration with NES and will use a national guideline 'knowledgebase'.

iii) After Requesting - Many radiological investigations require 'vetting' prior to booking. All order comms systems must support the ability for the department to request more information or reject a request outright. Furthermore it is highly desirable for the system to support a dialogue between clinician and radiologist. Manual vetting of requests is time intensive but necessary for certain groups eg paediatrics.

4 Diagnostic Decision Support

Decision support software exists in the healthcare domain in a number of forms and integrates at various levels with order comms systems and clinical databases. Much of it is still in its infancy of development with true integration across the UK limited by the lack of standardisation and interoperability between systems. Whilst it may be difficult to demonstrate a close link between such decision support and positive outcomes in terms of demand optimisation, there is nevertheless a strong empirical notion that identifying best practice with regards to test choice and facilitating consistent requesting behaviour on that basis would be in the interests of patient care and efficient diagnostic practice. Local teams should therefore consider the implementation of such decision support software at an early stage and make use of guidance in referral information sites (such as www.refhelp.scot.nhs.uk )

Conclusion

The implementation of activity to support demand optimisation is vital for modern, efficient diagnostic services. Diagnostic services must be equipped to work with and enable users to optimise requests for examinations within a patient centred context and be able to deliver effective knowledge rich reports to the point of care that deliver the maximum positive impact to a patient pathway. Much of this activity is dependent on the availability of specific IT functionality allowing automated data collection and requesting behaviour modification activity.

It remains clear however, that attempts to develop such automated and functional IT systems to support diagnostic demand optimisation activity, interoperability and standardisation are in their infancy, but nevertheless need to be developed and matured with a degree of urgency. These limitations should not however stop or limit such demand optimisation work implementation, while diagnostic services should look to incorporate such functionality described at the earliest opportunity as these systems/modules become available. Diagnostic service providers provide only part of the key to delivery of demand optimisation and the realisation of benefits from the approach. This means working across the diagnostic services in Scotland to reduce variation and working with users of the service to enable tailoring of demand and service provision with a view to delivering demonstrable outcomes that are consistent with Triple Aim.