Chapter 3
Organisation Benefits of Electronic Prescribing
The potential for IT systems and applications to facilitate changes in working prac- tices by automating mundane, logical processes is now well recognised throughout the business world. Indeed, much commercial system design methodology now seeks to model data and business processes, using tools such as UML diagrams, in order to design software that is the “ solution ” to the business challenge, regardless of past practices and procedures. Thus the introduction of a new software solution can lead to an organisation meeting its business objectives more efficiently, with a paradigm shift – a radical change in working practices – for those who are involved in the business area.
Healthcare IT applications such as electronic patient records (EPRs), EP and order communications have led to a paradigm shift in working practices, and indeed professional role, for many healthcare professionals. For pharmacists, this has been described as a move away from product- and process-centred work, towards patient-centred work, 1 and will be discussed at length in a later chapter.
options are useful as they increase the number of customer sites where a system can be installed without major code changes and enhancements.
(c) An appreciation of the business processes being modelled, and the assumptions taken when designing the software to support those processes, provide imple- menters with a valuable insight into why the software was designed as it was.
Consequently, there are a number of important principles of business process redesign that need to be considered by implementers of EP systems and associated healthcare software applications.
First, within an enterprise or organisational unit, as many of the business processes as possible should be modelled in order to provide a solution that is holistic, and that covers the vast majority of business scenarios that might arise in the organisation. A single system covering a range of business processes will be more efficient and consistent in its operation because common server platforms, data platforms and application algorithms will be in use.
Given the range of different types of business scenario and use case that can occur across healthcare, it is difficult in practice to produce systems that are truly universal in their scope. It is primarily for this reason, as well as for reasons of sys- tem ownership, that traditionally in healthcare, systems have developed in a “ silo ” manner as individual departments and professional groups have sought to automate their processes in a “ bottom up ” approach. Consequently, many healthcare software vendors have taken a modular approach, where a patient administration system (PAS) can be supplemented with an order communications module, an electronic prescribing module etc. Furthermore, in any particular healthcare enterprise, there may be reasons why a system may not cover all business areas – for example, where a satellite hospital or remote unit does not have full connectivity or system availability for communications or infrastructure reasons.
Nevertheless, with regional or national healthcare IT projects, such as the English Connecting for Health programme, there are now opportunities for large, highly configurable systems to be deployed, which aim to address as many health- care business processes as possible. Indeed, many software vendors are seeking to provide products based on “ service-oriented architecture ” where the structure of the system is based on the services it is intended to support, and processes that are common to all functions (e.g. terminology and decision support) are provided by single engines, which are integrated with the various service units within the sys- tem. While service-oriented architecture is of great benefit in supporting a large range of use cases in an efficient and consistent manner, it confers a uniformity on the system that may render it easier to interchange with another similar architec- ture, which has major commercial implications for software vendors 2 (Fig. 3.1 ).
Second, the scope of the business processes being supported must be clearly defined. Given the vast number of business processes and scenarios that are in operation in a healthcare setting, it is inevitable that some processes will not be able to be supported by a single system. This may be for infrastructure reasons, or because an alternative system, or a legacy system, is already in place, which the organisation does not wish to replace, or which is not easily replicated. In this situation,
0000774970.INDD Sec5:42
0000774970.INDD Sec5:42 7/11/2008 3:48:21 PM7/11/2008 3:48:21 PM
Principles of Business Process Redesign 43
it is important to define the scope of the new system clearly. It is also important to have a clear understanding of the type and capability of any interfaces that will be required with existing systems. This is important, given the way that, historically, systems in healthcare have developed in a “ silo ” manner (silo development).
Furthermore, interface requirements are of particular significance in medicines management since, in order to provide full business process management, an EP system would need to interface with a PAS, a pharmacy system, and an automated dispensing system (pharmacy robot) via the pharmacy system. Issues surrounding interfaces of this type will be discussed in detail later in the chapter.
Third, the significance of business processes must be clearly understood in their context before a software solution can be designed to support them. Take, for exam- ple, the UK practice of 28-day dispensing, or “ one stop ” dispensing. It is important that an EP system has the functions to support 28-day dispensing (a 28-day supply flag for items, with a reorder after 21 days algorithm etc.), but it is essential to realise that the rationale for 28-day dispensing is to prevent duplicate dispensing and thus streamline the discharge process. This awareness ensures that all associated func- tionality – e.g. discharge functions – will be designed and linked in appropriately.
Fourth, and most significantly, it is essential when implementing a new system that business processes are not re-engineered to match the system design, or tech- nological capability available, rather that the software is designed and configured to support current – and, most importantly, emerging – business processes. On one
Fig. 3.1 Service-oriented architecture
Laboratory &
Radiology Test Services
Medicines Management &
Pharmacy Sevices Database/
Terminology Service
Decision Support Engine Security
& Access Functions
Communic -ations Web
Services Appointments
& Scheduling
Clinic Management Theatres
Clinical Noting
&
Documentation Management
0000774970.INDD Sec9:43
0000774970.INDD Sec9:43 7/11/2008 3:48:21 PM7/11/2008 3:48:21 PM
hand, the appropriate technology must be available to ensure that an application can be deployed across an enterprise without any loss of performance; some early EP programs in the US failed because the technology used was not scaleable. 3 On the other hand, technology may fail to deliver benefits if it does not meet needs, or it requires that practice is altered to accommodate system use.1 Indeed, experi- ence from the US suggests that healthcare providers need a technology strategy to ensure that technology supports the organisation’s goals, rather than fitting busi- ness processes around the available technology. 4 Appropriate use of electronic systems to support current and emerging business processes will be facilitated by highly configurable systems, use of service-oriented architecture and the involve- ment of clinical professionals and domain experts in their design.