 |
For those of you about to (finally) begin to implement any element of the National Programme for IT (NPfIT) then you need to be aware that this experience is likely to be very different to anything you have endured before. All your past experiences of implementing information systems will be challenged in a very different environment which is far removed from the traditional customer-supplier relationship.
The experiences at Milton Keynes General Hospitals NHS Trust in being the third site in the Southern Cluster to implement PACS and fourth to deploy CRS came with many lessons learnt and worth sharing. If you start from the premise that your past experience counts for little then you will be better prepared for that which is about to happen to you.
A very different customer-supplier relationship
For a start you have to accept that you are unlikely to deal directly with the system supplier. The Local Service Provider (in this case Fujitsu) is very protective of their system provider partners. Besides the obvious difficulty in communicating through a third party there is the added problem that the LSP knew much less about implementing hospital systems than the customer.
Of the first 19 people I met from Fujitsu, only one had any NHS experience. This is not to say that they weren’t very good people, many of them were extremely proficient but trying to extract the nuances of patient waiting list suspension rules from a guy with only retailing experience made for interesting dialogue. The differences between patient episode, patient spell and point of sale were never mastered by some.
Discerning suppliers have always made an assessment about the capabilities of customers to successfully implement their product. Apart from the income there is little benefit for any supplier in commissioning a system that is unlikely to have a productive outcome and a problematic existence. Historically those assessments have been kept within the confines of the supplier network, under NPfIT, and with the business already won, they are much more overt in making that assessment.
As an NPfIT customer you can expect to have to justify your IT strategy, demonstrate clinical and director level commitment, have your infrastructure and desktop population examined, provide details of technical expertise as well as be interrogated about your Information Governance Toolkit scoring and intentions.
In many ways this is a reversal of past practice with the supplier checking the suitability of customers prior to implementation. In many respects this is no bad thing. However the balance is wrong with the customer having very little opportunity to examine the credentials of the provider and even less sway in changing anything which concerns them. This can cause real difficulties for both parties.
Problems with PACS
During the PACS deployment in Milton Keynes there were three major problems, any of which could have halted that programme.
The first problem was funding. At one time the trust board refused to support the business case because of the affordability issues of capital investment. The same funding issue also proved to be an issue for subsequent trusts and was only finally overcome with regional intervention and financial support.
The other two problems would never have arisen in a traditional procurement. The LSP insisted that the PACS workstations could not have virus protection software installed on them. They contended that the contract performance (and therefore associated payment) levels could be affected by third-party software and they would not allow good IT practice to jeopardise their payment stream.
Similarly there is no provision for customer, or user, acceptance testing in the NPfIT contract, therefore the LSP was not prepared to allow such work to be undertaken. At Milton Keynes we were not prepared to implement a major operational system ignoring such key steps and this led to further conflict.
One might have expected CfH to intervene under such circumstances and they did – they told us to take our virus software off our workstations and not to use the testing scripts we had developed prior to going live. The repercussions went to chief executive level before such irresponsible practices were avoided.
Where does CfH fit?
This experience illustrates the changing relationships that NPfIT has introduced into the commissioning of health systems. Perhaps the most important of these is that the recipient of the service the customer. The LSP sees CfH as the customer and both these parties are increasingly contract-focused not customer-focused. As the intended customer this is a very uncomfortable development.
Don’t be misled into thinking that CfH may be on your side in any dispute, they have their targets as well which, in many instances, are the same as the LSP.
Seasoned campaigners will struggle with this change but can take heart from the fact that the relationship reverts to type when ‘Added Services’ are being negotiated. This is not just about new pathology, pharmacy systems etc but can include data migration, data warehousing and system integration services amongst others as part of your CRS deployment.
There is a major piece of work in determining exactly what is in and out of the CRS central contract. With CfH’s insistence that trusts don’t need to see the contract that covers every deployment then it is inevitable that there will be some ignorance about the true costs and responsibilities of the programme.
Check who is responsible
Make sure you know the full cost and who is funding all aspects of data migration, data cleansing and system integration – here’s a clue, it’s not the LSP or CfH. Although data warehousing may be included in the central costs be sure you examine what this really means. The constrained data warehousing model on offer is unlikely to satisfy the minimum requirements of any trust seeking foundation status or taking Payment by Results seriously.
Be clear about the support teams required to introduce CRS to an organisation and the contractual obligations you are entering into. The contract places considerable emphasis on change management and every deployment requires local investment in prescribed staffing levels to support this intent. Ignore them and the contractual consequences are greater than the actual costs.
Flaws in the CRS design model
Good practice can only take you so far and at some stage there is a leap of faith to be performed. Much has been made of the clinical reaction to commissioning problems at Milton Keynes; never have I been involved in a project which has had a greater level of clinical involvement at all levels. Good practice would never have allowed training to be undertaken on a different version of the system to that to be implemented but how can you totally prepare for a merger of patient data from three organisations?
The Milton Keynes data was merged with data from two other trusts already on the same CRS platform. The NHS number being the key identifier to ensure data integrity is maintained. This is a totally new concept with three trusts accessing the same Master Patient Index (MPI). The same patients could, potentially, be on the same waiting lists at all three hospitals and have in-patient history at all three.
You can do as much testing and data cleansing as you like but at some stage there has to be that leap of faith when you merge more than a million patient records. This design would pass very few good practice checks and is a result of contractual expediency rather than operational preference. It is difficult to envisage any similar project having no problems at all in spite of the Milton Keynes experience. That risk has been introduced by a flawed approach to design which is driven by reducing costs through the obsession for centralised computing in an age of devolved technology. This experience must make one fearful for a fully functioning National Data Spine (NDS) and although the concept is commendable I for one have no confidence in the likely outcome. Unfortunately a discredited NDS could be the legacy by which NPfIT is remembered.
Improved governance
There are many benefits in running a programme of work with your LSP, not least being the introduction of proper governance arrangements within a major programme of work which may not have been as carefully adhered to in the past. However such scrutiny will bring a higher profile and the inherent closer attention that may not always serve pragmatic progress well. Pragmatism does not feature prominently in PRINCE2 so be prepared to follow the manual as others most certainly will, if not at the time, most certainly when anything may go astray at any later time.
The composition of the CRS Programme Board needs very careful deliberation and any acute-led CRS deployment must ensure that the local PCT(s) are fully involved, not least because they are the probable future paymasters. Executive director level and clinical involvement are crucial and I would strongly suggest that the quality assurance function is led by a senior clinical consultant.
The real challenges of implementation
Working with clinicians is a real challenge as many are highly intelligent, have strong views, have a different agenda to management and rarely agree totally with all their peers. In my experience you will never get any clinician to be fully representative of all their colleagues but that is no excuse for not trying.
An even bigger challenge is in galvanising existing system suppliers to help you untangle and decommission their systems, and as a result ending their income stream. For those most disaffected by NPfIT and casualties of the bidding war, there is one last gravy train for them to tap before disappearing into oblivion. Some suppliers have profited immensely from the delays to CRS, through massive increases in support costs over the last two years with minimal development in return.
You can’t do it without them and the migration and preservation of your data will undoubtedly become an increasingly costly and lengthy process as expertise leaves another sinking ship. Your critical path deadlines are of little interest to them.
The understandable reticence of current suppliers to maintain and develop their systems has done a great disservice to the NHS resulting in a development hiatus which has further tarnished the reputation of computing within the service. Don’t under-estimate the costs or difficulties in ending this relationship.
Be true to your principles
It is so easy to be steam-rollered by the CRS bandwagon and the (sometimes) misguided enthusiasm of the uninitiated NHS novice but it is imperative that NHS IT professionals remember who they are really working for. Be true to your principles and there is still a chance that you will deliver a successful programme that will provide real benefits for the patients, and the clinical and administrative population in your community.
Don’t be overwhelmed or bullied by the tactics of some who would have you act as their mouthpieces and faithful lapdogs. It’s clear that many aspects of NPfIT are not defendable in a non-biased community so don’t try. Expend your efforts in promoting the realistic benefits that are tangible and demonstrable and arm yourself with as much experience and wisdom from successful deliveries as is possible. I wish you well.
Jeff Jacklin has 35 years experience in the IT industry, the last 20 at director level within the NHS and was Head of ICT at Milton Keynes General Hospital until April 2006.