Future Funding of GP Computing

I’ve have heard Katie Davis (no relation), the new head of the DH Informatics Directorate, speak twice in the last few days and on both occasions she has stressed the Government’s desire to create a vibrant market for the suppliers of Health IT systems. This is very much to be welcomed.

Current arrangements for the funding of GP Computing come to an end soon and at one of these meetings, in answer to a question from the redoubtable Dr Mary Hawking, Katie Davis gave assurances that there would be future funding for GP computing, but would not be drawn on the form it would take. This both reassured and worried me.

The cost of GP computing has always been fully met by the NHS (either directly or indirectly) but the way this funding has been delivered has had and will continue to have a critical effect on market dynamics and decisions about future funding will determine who “vibrant” this section of the market is with important ramifications for the whole market.

The UK wide 2004 GP contract gives GPs a contractual right to a choice of GP system and currently funding for GP computing comes from two central sources: Where GPs take solutions from the LSPs under the NHS NPfIT it comes from the NPfIT otherwise it comes via the GP Systems of Choice Programme (GPSoC) under a national framework contract which includes all of the current GP suppliers (for practical purposes this contract was available to all who wanted to participate at the time it was let.) In both cases the responsibility for managing the provision of systems at a local level in England lies with PCTs; there are other arrangements in the other home countries.

A number of things will happen over the next couple of years which have the potential to result in radical change for GPs in England.

1. The NPfIT LSP contracts come to an end in 2013; but are the subject of ongoing discussions that could lead to changes.

2. The GPSoC contract comes to an end in March 2013

3. PCTs cease to exist in April 2013 – assuming the Health Bill makes it through the Lords.

4. Finally, there is potential for changes in the GP contract

If properly coordinated these changes create an opportunity to ensure competition and innovation and a vibrant market. However, the history of such coordination on this issue is a very unhappy one and we need action now to ensure it happens.

There are a number of issues that emerge in my mind which need to be addressed:

• There must be coordination between the different parts of the DH/NHS responsible for these changes including, as far as it affects them, other home countries. The BMA and in particular the BMA/RCGP Joint GP IT Committee has a key role in making sure this happens.

• The local coordination role currently undertaken by PCTs MUST go to the Clinical Commissioning Groups (CCGs) not to the National Commission Board (NCB). As. I have said previously, and it is widely acknowledged elsewhere, successful IT requires frontline (particularly clinical) engagement. The shift of responsibility for IT provision from individual practices to PCT resulting from the GP 2004 contract undermined this engagement moving closer to GP and other clinicians via the CCGs with help rebuild engagement moving to the NCB would fatally undermine it.

However, while CCGs should hold the responsibility many are not equipped to manage the practicalities of this role and arrangements should enable CCGs, either singly or in local clusters, to contract out day-to-day responsibility to informatics services or Clinical Commissioning Support Groups in the public, private or third sectors.

•New arrangements need to secure access to GP data for analytic purposes (see my blog http://wp.me/s1orc5-110 )

•Transition arrangements for those with systems under LSP contracts should be such as to bring all GPs in to a common framework.

• We need to retain choice for GP practices and keep this enshrined in any renegotiation of the GP contract. I can see good arguments for a common choice at a local level, but on balance I believe that this should be by agreement between practices. I fear that if we remove choice at a practice level altogether we risk ossification of the market which will stifle innovation and competition

• New arrangements need to open to scrutiny, like GPSoC not secret like the NPfIT contracts

• We need to ensure that we don’t continue to lock the market to new entrants or just to those who offer a GP-Centric solutions. The future IT needs of GP practices may well be better meet by a new generation of multiple cloud based apps which make the current boundaries between care settings and the systems that serve them meaningless –We must not create artificial barriers to such potential new approaches. If we lock general practice in a bubble so that it can’t be part of wider solutions that cut across care-settings and organisational boundaries we risk doing damage across the whole UK Health IT market not just General Practice.

It is not clear whether the intention is to put a national framework in place but this would seem to go against much of what I’m hearing about local procurement of IT. I think there needs to be some national coordination and standards, but this not need go as far as formal framework procurement. I favour some central guidance perhaps with a model contract that can be amended for use at CCG level (probably done through share Clinical Commissioning Support Group or Local Informatics Services.)

Getting this right will be critical to the creation a vibrant market and time to do this is running out. I know that some work is going on but are we covering all the bases?

Deceleration of potential conflict of interest

I don’t believe that I have any material conflicts of interest in relation to the matters in the blog. Neither my future plans or those of any current client are directly effected by future decisions on the funding mechanism for GP computing.

Lessons from GP Computing

UK GP computing leads the way globally in the application of clinical computing at the point-of-care and for many years was the only example of the widespread implementation of clinical computing at the couch-face.

It is interesting to examine why GP computing was, and still is, much more successful than clinical computing elsewhere in the NHS and what lessons, if any, are transferable from general practice’s experience to other care settings.

To carry out this examination requires an understanding of the history of GP computing. In writing this I am struck by the parallels with a the story of the development of the London Underground, told in a book read on holiday “Subterranean Railway” by Christian Wolmar. This tells of a success built on innovation, mainly unsuccessful commercial opportunism, limited (but occasionally enlightened) state involvement (importantly not in the innovative phase), luck, and fierce competition between suppliers (attenuated by self-interested cooperation). Why I was reading a book on the London Underground while on holiday in Kefalonia is a question I will leave readers and my family to ponder.
GP computing in the UK can trace it roots back to early research-funded experiments in the 1960’s but only started to get a significant foothold at the end of the 1970’s when microprocessor based computers made multi-user systems running operating systems like OS9, BOS, Xenix and Mumps affordable to innovative practices (interestingly it was these machines rather than the early PCs, which appeared at the same time, that powered the first generation of systems).

These systems were developed by GPs themselves (or those very close to general practice) and were focussed on automating processes that were currently onerous and which looked like easy targets for computerisation – notably, patient age-sex registers and the production of repeat prescriptions. These tasks were also attractive targets because their automation brought financial benefit (substantial cost savings around repeat prescriptions and revenue opportunities and cost savings around age-sex registers). There were few grand plans systems were built quickly and deployed quickly, most were flaky, but the small band of enthusiast soon discovered what worked and what didn’t. Some big companies entered the fray (DEC, IBM, Centrefile (a part of Nat West Bank)) but it was the gifted amateurs who were close to the requirements that built the successful systems and all today’s market leaders grew from small innovative start-ups (all but one of them from systems that first appeared in the early 1980’s).

This gives us the first few lessons which I think are transferable and still hold good:
Development of systems has to be user-centric with end-users and other domain experts involved throughout the whole system life-cycle, not just in the requirements gathering stage.

Rapid prototyping and agile development work best, particularly when extending IT in to new areas or using it in new ways when we don’t really now what the true requirements are and what’s going to work best.

Users will put up with and engage with a flaky system that does something that is actually valuable to them. If user responses to a new system are dominated by complaints about quality and usability it probably means they do really value the functions it is designed to perform.

The market grew slowing in the beginning and in early 1980 Government intervened with the disastrous Micro’s for GP’s scheme which killed off many of the embryonic commercial suppliers and nearly destroyed the market, but this had two positive effects. Firstly, it resulted in the availability of prescription forms on continuous sprocketed stationary (making it much easier to print prescriptions, although confusion over standards meant these new forms were produced for many years at a non-standard width!) Secondly, it led to the formation of the General Practice Computer Suppliers Association (now subsumed in the Intellect Health Care Group) which demonstrated that suppliers could work together in the public interest (as well as their own) and formed an effective working relationship with officials from the DHSS which helped avoid future inappropriate Government actions.

Some more lesson here.

It is often simple things – (like the provision of prescriptions forms and changes in regulation to allow their use) that can enable new technology to deliver more efficient business processes.

The interests of suppliers, with a long-term commitment to a market, are much more closely aligned with each others and the interests of customers than is often understood. Suppliers, customers and regulators can and should work together and such cooperation will tend to drive out suppliers seeking to gain short-term advantage at the expense of their customers.

There is scope for multiple interpretations of standards (even something as apparently simply as the standard widths of paper) effective standards implementation require earlier testing to prove interoperability – With today’s complex standards IHE provides an exemplar of how this can be done with their Connectathons www.ihe.net

By the mid 1980 about 5% of GP practices having some sort of GP system, but while a few pioneers had screens in their consulting rooms most of these systems were used primarily in the back office. It was at this time that a number of people recognised the potential commercial value of anonymised data from GP systems and two companies, mine, AAH Meditel (now subsumed in iSoft/CSC and VAMP (now INPS/Cegedim)) launched schemes which offer sophisticated multi-user systems to practices at no cost in return for anonymised data. These schemes (like some of the early investments in the London Underground) were eventually commercially unsuccessful (I lost £13 million of investors money and VAMP must have lost a similar amount) but between us we left a legacy of over 2000 computerised practices who chose to keep their systems As well as this direct effect the “Free Schemes” demonstrated the benefits of computerisation and over this period many other practices computerised outside of the “Free Schemes” and the Government introduced a direct reimbursement scheme for the cost of GP systems (deliberately designed to undermine the business models of the “Free Schemes” of which they disapproved). By the time the free schemes ended in 1990 GP computerisation had exceeded 50%.

The widespread implementation of GP computing made possible various developments in General Practice which would not have been possible if the practicality of GP computing had not been demonstrated. These included the data driven 1990 GP contract, GP fundholding and early developments in EDI between GP practices, Health Authorities and hospital laboratories. I remain particularly proud of the work my company did in EDI We had established an electronic network with daily communication with nearly a 1000 practices (by far the earliest such network of any size). We used this network to collect data (VAMP used disks in the post), but also opened it up to allow early experiments with EDI. Sadly we lost the network with the “Free Scheme” and failed to commercially exploit our early lead in EDI.

So some further lessons:

Young and foolish entrepreneurs should be encouraged to deploy innovative solutions, as the investment will benefit healthcare independently of their commercial success. It is worth noting that we would not have either the London Underground or the Internet if numerous hopefuls had not lost their shirts in the process of building them.

Benefits don’t flow from IT but from the changes in ways of working it makes possible. IT can both catalyse and enable changes in business process and culture. The quality and efficiency of general practice today has been much enhanced by the changes GP IT has enabled to happen over the past 30 years.

Today, virtually all GPs use a computer in the consultation, the majority of practices are paper-light (they don’t routinely refer to paper records) although they have to scan much incoming paper to achieve this and most mid-carer GPs have never known general practice without a computer.

As well as the lesson that flow from the history there are other factors that enabled GP computing to be successful which relate more to the nature of general practice and which don’t apply in many other care settings these include.

The scale and complexity of general practice. General practices are not simply organisations and there is considerable variation between their ways of working and thus their IT requirements, but compared to an acute hospital or large community service they are relatively homogenous, quite small (typically 10 – 20 people) and it is reasonable practical for a single person to have an intimate understanding of all they do. Replicating this level of understanding in larger organisation is close to impossible and while more formal methods of requirement gathering can help the answer probably lies in avoiding the problem by avoiding “lowest common denominator” monolithic enterprise-wide systems and instead focusing on multiple “best of breed” systems able to interoperate to provide not just enterprise but community wide operation.

The nature of GP Encounters. Most GP encounters occur in an office environment where size and portability of equipment are not an issue and are off a nature where infection control is not a major concern. Technological advances are now close to removing the problems of using systems on the move or in difficult environments. We already have equipment in form factors to suit mobile use, with ubiquitous wireless LAN and WAN a reality in many places. We have devices that can be wiped clean and well developed voice recognition enabling use in most clinical environments, with the short-term prospect of cheaper and even more usable mobile devices, 4G connectivity and new hands-off human-commuter interfaces it will become possible to deploy IT in even the most difficult clinical environments.

UK GPs are “for profit” businesses and until 2004 were the direct customers of GP systems suppliers. This meant that the frontline user was making the purchasing decision, that they demanded a clear return on their investment, were willing to fully commit their part in achieving benefits and the associated ROI and would robustly hold suppliers to account to play their part.(as an ex CEO of a GP supplier I still have the scars!) Creating the same relationship with larger health providers is not possible. However, it is possible to achieve some of the features of this relationship by ensuring that frontline staff takes a leading role in procurement decisions (not just participate in the procurement), that personal and organisational incentives are aligned with benefit realisation (which must themselves be aligned with real business drivers.) i.e. pretty much the opposite to what happen in the NPfIT where system suppliers were disconnected from frontline users by the imposition of a process obsessed and dysfunctional “communication” channel via the LSPs and the BabyFITs (the local arms of the NPfIT.)

The Independent GP Systems User Groups have be a critical factor in the success of GP Computing. I think the first to form was the Abies User Group (now subsumed into iSUG), but all of the major systems spawned user groups. These groups performed two important set of functions. Firstly, to establish robust communication between the suppliers and their customers, both challenging and supporting their suppliers to ensure end-users interest and priorities were given due weight. Secondly, to provide an infrastructure to enable ideas and practical experience to be shared between users. The User Group national conferences attract many hundreds of delegates and many of the group have vibrant local branches. The User Groups also pioneered the use of what we would now call “Social Media” with bulletin boards and mailing lists operational by the end of the 1980’s where users could share experiences and get solutions to problems and development of these early services still provide vital support and resource for end users today.

Competition GP computing in England and Wales was a fiercely competitive environment with many suppliers competing for GPs business with around 30 – 50 serious players in the market at its peak (there are some much higher figures for the number of suppliers quoted but these are mistaken). Goverment intervention with the “Micros for GPs Scheme” in the 1980s and the NPfIT in the 2000s damaged the market and reduced competition, but thanks to the robust response of suppliers and their GP users the market while now more mature (with just 5 suppliers) remains competitive and it is critical that changes which will flow from the end of the NPfIT and GPSoC Contracts done further undermine competition in the market (I will expand on this in a future blog).

In summary, much of the success of UK GP computing can be put down to luck with the right technology being in the right place at the right time for the early pioneers to pick it up and run with it. In the complex world of health informatics GP computing was a relatively easy and fertile place to start. Some of the factors that made UK GP computing a success where unique to that environment, but in most cases they are generalisable at least to some extent and we would do well to consider how the lesson from this success can be applied elsewhere.