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 (thanks to https://www.megapath.com/voice/lines-pri/) 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.