A clinical informatics project has many phases. At different stages, the chief clinical information officer has different areas to prioritise, and different roles to play
1. Project initiation
Any clinical informatics project will start with an embryonic idea: wouldn’t it be great if clinicians (nurses, medics and allied health professionals) could do x, y and z to make their clinical practice easier, safer, more effective and efficient?
These are the stories that are continuously generated everywhere within clinical settings. The trick is to transform them into a clinical informatics project proposal for development.
A pivotal role for the CCIO is to collect these stories, logging them in some electronic format that can be shared with others. The stories will be pointers to formulate an idea which can be transformed into a project for development.
There is a fundamental component that needs to be illustrated clearly: what is the driver for the new system? Is it clinically focused/driven? For example: let’s develop a more efficient handover system. Or it is a corporate/target driven request? For example: we need a more transparent system to record some national compliance requirement.
The CCIO role can be seen as an integration engine, connecting different stakeholders together, transforming their needs/demands/wants (messages) into a common language and processing/displaying these in one common system.
It is therefore crucial that the CCIO feels comfortable at board and corporate level, and is respected and able to engage at clinical level within all divisions and specialties (see Chapters 4, 5 and 6 for more information on engaging clinical and executive colleagues).
- Clear outline and acceptance of project initiation document or business case.
- Resources. Not just budgetary (see Chapter 2 on procurement) but crucially manpower resources. For example,IT, business/service management, clinicians lining up wishing to be associated with the project.
- Continuous scope creep (new user requirements being added, making the project more complex and more difficult to achieve).
- Requests to refine the business case. If this happens more than once, assess whether the project is truly viable.
Be wary of:
2. Procurement
The CCIO should be involved in an advisory capacity to make sure that the correct system is purchased/sourced. He or she should support those within the organisation who do procurement on a continual basis.
In my view, the CCIO should take part in any preliminary discussions with vendors/suppliers and clearly outline the clinical user requirements, identifying how efficiently the supplier would deliver components and sustain the maintenance of systems. Networking outside the organisation can be useful to get a ‘feel’ for the credibility of the vendor.
It may be possible to run a pilot, which will deploy and embed a new system rapidly in small scale. This makes it possible to check that the system will be scalable and that it fulfills its function according to user requirements, or proof of concept.
It is also an excellent way to engage with the supplier and establish commercial relationships. These will help ensure that the procuring phase delivers return on investment and delivers the benefits that were proposed.
The role of the CCIO must not be confused with the role of the project/programme manager. These roles are distinctly different. The project manager is the person who should be associated with resource management and needs to own this function.
The CCIO is the clinical advisor. He or she has a good understanding of the clinical work flows within the different settings and have an understanding of what type of technology or innovation could be utilised. On occasions the CCIO and project manager roles may be performed by the same person, but this needs to be clearly specified and understood by the organisation.
Success factors at procurement stage:- Clearly agreed release of resources for hardware/development/project management – without any delay.
- Well thought out measurements of benefit.
- Resource constraints. If financial/resources run out or are constrained it means that the project needs to be adapted or scaled down.The most likely impact is that the momentum and appetite for the project will be lost. This leads to frustration from all stakeholders and the CCIO tends to be in the firing line of discontent.
- Not having established clear measurements for the benefits analysis. When this is lacking, it is easy for any stakeholder to cull the full project (to reprioritise to another project/system solution) since it is difficult to rationalise why any pilot was a success, what change of practice has occurred and what benefits are achieved.
Be wary of:
3. Development/configuration
This is the exciting part of the project pathway – new or grounded theory is developed or utilised in a new system. This is where the CCIO role comes into its own.
The CCIO is able to work alongside clinicians (nurses, medics and AHPs) to test/showcase as well as tunnel into the key requirements, transforming the clinical stories into development items for release.
Much time is spent between the CCIO and the supplier and IT development architect to go through various use-cases (clinical scenarios). This makes it possible to outline in detail the human and systems behaviours, how messages need to flow between systems, and how these messages should be presented to the user.
In my organisation, we have an in-house development team and are developing a best of breed electronic patient record. The CCIO pre-tests any new system development. For example: can the system be used in all clinical settings or are there any additions that need to be developed to provide inclusion of specific areas?
Using the CCIO as the first clinician to test the prototype system can greatly reduce the time of development and user acceptance.
It is obvious that the CCIO cannot possibly understand every detail of every clinical workflow, and that is where it is important for the CCIO to have high visibility through the divisions and the clinical teams.
I maintain this through visiting clinical teams regularly at clinical meetings or handovers, targeting the junior doctors in their regular established training sessions. This helps ensure the development and output is consistent and useful for those who provide direct care and treatment.
Success factors at development/configuration phase:- Prioritisation. Not everything will be able to happen at once. Prioritising what it is most important to do first, and ensuring that the resources are available to do it, will be central to delivering a quality system. When resource, prioritisation and quality are in sync, a positive momentum of systems delivery is sustained, driven by the clinical function, facilitated by the CCIO.
- Well tested systems signed off by clinical staff/super-users prior to going live. This seems obvious but can easily be overlooked and rushed through. Remember that no software is 100% perfect. Glitches and bugs will be identified – the trick is to identify as many as practical prior to going live.
In my organisation, the EPR clinical focus group members help with testing. This can be achieved by taking the UAT (user acceptance testing) systems into the clinical arena where they work, rather than setting up meetings or workshops when it will be difficult to get staff attending. - Poor clinical prioritisation and/or development/IT resources prioritisation will result in poor quality clinical informatics solutions.
- Poorly tested systems. In my experience, clinical staff are happy to participate in testing prior to systems going live, or to trial them. However, when systems are being deployed that do not work or support the clinical workflow, staff become easily frustrated and will seek out other means, bypass the system, and create alternative sub-systems to achieve their aim. It will be very difficult to build up trust again with the result that clinicians are reluctant to reengage to use the system.
Be wary of:
4. Deployment
This phase is when the project/roll out plan, managed by the project manager, becomes the crucial tool. The role of the CCIO in this part of the process is to support the project manager and engage closely with the rollout team.
Humans do not like change – we are creatures of habit. There will be clinicians who will be quite verbal in expressing their (and their team’s) reluctance to change practice. They may argue that their current practice has been tried and tested, so why change?
The CCIO’s role is to reassure and offer support to clinical staff on the change of practice. This will involve listening to issues raised by staff and being highly visible in engaging with those in the go live areas – where necessary, feeling their pain and brokering solutions.
It will be advantageous if the CCIO is fully familiar with the product/new system being introduced. Being able to demonstrate the functionality of the system in professional sessions or on a one-to-one basis will help decrease anxiety and improve ‘buy-in’ from frontline staff.
My experience is that this will be a period in which the CCIO’s communication skills are tested to the limit, since many of the key stakeholders (the service management, clinical function, IT resources) will be looking at him or her for guidance in order to see the deployment through to the end.
Success factors during deployment:- Respond as soon as practical to issues raised by frontline staff.
- Roll out not implemented according to plan, or a system which has not been fully delivered as intended. This can cause stagnation and ultimately will lead to lost momentum.
Failure factors:
5. Handover and project closure
This part of a project is crucial from a CCIO’s perspective. Officially this is where the project is handed over by the project manager to the service or organisation. It means that responsibility to embed, sustain, and manage the new clinical system shifts from IT or project management to the operational function in the business.
If the CCIO has been actively engaged and associated with the previous stages, it is very easy for the organisation to use him/her as the key person.
In my opinion, however, it is important – if difficult – for the CCIO to refrain from becoming the systems administration, super user and system expert all in one. The danger in these instances is that the CCIO gets bogged down in the local operational aspects of the new system, rather than concentrating on new or other similar programmes.
Success factors at handover stage:
- A structured methodology around sustaining and improving the system throughout all clinical settings.
- An organisation-wide focus group which engages on behalf of peers to manage the newly adopted clinical systems.
- Becoming permanently responsible for keeping the new ways of working sustained.
- No one else being in place to drive or coordinate the newly completed system.
Be wary of:
Conclusion
Seeing an IT project through from idea to successful implementation is no mean feat. CCIOs can greatly increase the odds of success by offering support at each stage. It will be a challenging task, but can be incredibly satisfying as well.