System Design

In the top down projects the design phase may involve quite disparate activities, for example, the detailed design of new pathway processes and organisation and job design to define the roles staff will play in the new pathway. The e-health strand of design, in most cases, was separate and to

some extent considered after these strands of development. In the design of CECS, for example, e-health development came after the re-organisation of intermediate care and in FEP the new pathway was in operation long before serious attention was paid to the e-health support that it needed. The maturity framework presented in table 9.2 recognises that there will be both technical design processes and associated design processes. In the examples in the two LHCs it is the ‘associated changes’ in the pathway process and the organisation that is driving the technical design.

The overall technical strategy in both LHCs is to establish a technology infrastructure on which the specific e-health services for a pathway can be constructed, i.e. using FUSION or SystmOne. In practice in the top down cases this has been the pattern for the Stroke pathway development and CECS. In the case of Retinopathy Scanning a different stand-alone system (OptoMize) was used (and mechanisms for getting information from SytemOne and other systems had to be found). In the Frail Elderly case the plan is to use a combination of iPM and FUSION as the basis for e-health support but with additional elements such a lap-tops and telehealth equipment and the ability to share data with the social services system, Paris. The pattern is to use a central platform and build on it through ‘middleware’ to provide inter-operable services. This means that, for these new developments, the need to procure new systems was limited to middleware, laptops and telehealth equipment. Making use of a pre-existing system has of course the potential disadvantage that it may not be able to accommodate the needs of the new development.

A long-standing issue in technical systems development has been the extent and effectiveness of user engagement in the design process. In the cases we examined, once a sub-part of the overall project was defined as an e- health development, the project management methodology PRINCE2 was deployed in both LHCs. This is a mature, well-documented set of procedures that manages a project through every stage and includes, for example, mechanisms for enabling users to ‘sign off’ the outcome of every stage. The methodology is also used in relation to bottom up projects although in a ‘light’ form as befits a small-scale project. A significant feature of the technical design process in both top down and bottom up projects is the role played by clinical facilitators or ‘hybrids’ who act as the intermediaries between the user community and the technical informatics staff. They play many roles; translating user needs into a form informatics staff can act on, explaining technical issues to users, training users etc. There is a long tradition of developing ‘hybrids’ in the NHS and it appears well- institutionalised in both LHCs. Whilst the role is well established, it is not so clear how one is trained to be a hybrid; as many of them reported ‘you learn on the job.’ Although the hybrid role is in place and the project management methodology that is adopted establishes formal user roles in the design process, there remains evidence, as presented in Appendix 3,

that the users often feel uncomfortable in the design process; that they do not understand what is being asked of them, their requirements are not really listened to etc.

In some respects, once a technical project has been established, it is governed by a mature set of processes many of which are in place to manage the relations between informatics staff and the user community. And yet in the big projects it does not lead to the initial systems meeting the needs of operational staff. This may well be because the scope for design is quite limited at this stage as may be the resources and time before deployment. The scope for technical innovation may also be limited by the need to use a technical infrastructure that was defined before the project was initiated. Together these factors may make it difficult for technical staff to respond to emergent requirements from users as they begin to understand the system that is about to be delivered. It seems more likely that the main role of user representatives will be to prepare their colleagues to receive the system rather than to challenge design decisions.

9.5.4 Implementation

Many of the procedures often labelled ‘change management’ are in place for the ‘go live’ stages of top down projects in both LHCs. In addition to the technical processes associated with equipment deployment and system testing, these include processes for establishing ‘user readiness’ to receive the system such as user registration and training. They also include the establishment of user champions to act as both explainers and motivators to their colleagues. All of these processes are well established and the clinical facilitators play a prominent role in the process, for example, in training the users or ‘training the trainers’.

These processes get the users ready to receive the new system but they do not deal with emergent problems, e.g. when there are unpredicted consequences of using the system for working practice. There are many implementation processes documented in the literature that are recommended as precursors to full roll out to identify and deal with such issues, i.e. scenario evaluation, testing the system in trials and pilots and conducting formative evaluations. In the cases we examined there is some evidence of the use of trials for component parts of systems, e.g. trials of laptops. There is also evidence that when timescales get squeezed, and there is pressure to implement the system, trials get abandoned or curtailed, e.g. trials of digipens and laptops. A trial, of course, may well reveal issues that need attending to before full ‘roll out’ and it may therefore be another cause of delay in the project and it may be cancelled for this reason.

The result of this approach to implementation is that systems get installed, i.e. they are in place and working, but they do not necessarily get adopted

widely by the user community, e.g. whenever users encounter implications of using a technical system that are problematic for their working practice they avoid using the system facilities that cause the problem or they find a ‘workaround’. Thus, a fax is requested rather than attempt electronic sharing, registering a patient in the stroke register is delayed until discharge from the ward, more tests are conducted on a patient rather than searching electronic records for recent results, patients are not removed from the intermediate care listing when they die, records are either non- existent or incomplete because of the double input load they create for users etc.

As the final part of the formal process of delivering a system, implementation is often squeezed if earlier stages put pressure on the need to deliver ‘on time and to budget’. The mature parts of this process in the two LHCs are those that have to be undertaken to get the technical system installed; it is the parts of the process that help users make the links between technical systems and their working practices that get squeezed and they remain immature parts of the process.