Category Archives: GP Computing

GPSoC – PQQ Deadline 4th July

This procurement is NOT just relevant for those in or wishing to enter the GP clinical systems market – Don’t miss your opportunity.

The new GPSoC procurement provides an important opportunity for anyone who wants to sell products or services in or which interoperate with UK general practice. The OJEU Contract Notice was published on 28 May and  has now been followed by more information including  the Memorandum of Information  and a link to request the pre-qualification questionnaire (PQQ).

The deadline for submission of the PQQ is noon on 4th July and Woodcote Consulting stand ready to advise and assist anyone who wants to explore these opportunities further.

This framework is very broadly drawn and while its core purpose in the provision of GP Clinical Systems to English general practice it provides a procurement vehicle  which could provide a route to market for a wide range of apps, digital tools and services for use in general practice or related to interoperability with general practice from other parts of the care system , with the  framework available for use by any public sector body across all the home countries in the UK.

There are three lots.

Lot 1 is centrally funded and relates to  GP Clinical Systems and certain high priority subsidiary products and apps

Lots 2 and 3 are not centrally funded but provide a flexible procurement route for local NHS or other public sector bodies wanting to procure the products and services covered. Lot 2 covers additional GP IT services while lot 3 covers cross-care setting interoperable services. My reading is that these lots could also include patient facing apps and services which GP Practice, CCG or CSU wish to procure for use by patients they serve.

The future GPSoC Contract also place a requirement on principle system suppliers to provide open interfaces to third party products and services, which together with the procurement framework provided create a very significant opportunity for vendors large and small in this key market, which all vendors should investigate. If you would like to explore how we can help contact Ewan Davis +44 207 148 7170 or +1 (347) 688-8950

An ESB for GPSoC Phase 2 ?

A key feature of the proposed new GPSoC contract is the opening up of interfaces of the principal GP systems to subsidiary system suppliers (this can include pretty much any product or app that might be offered in the primary care market.) The plan is to address the interfacing issue into two phases which will start broadly in parallel, but deliver over different timeframes.

Phase 1 is intended to be available from day 1 on the new GPSoC contracts and will simply place a contractual obligation on principal suppliers to make available broadly those interfaces they currently make available at their discretion (although some principal suppliers will have a little work to do to meet the minimum requirements.)

Phase 2 aims to make available a standard interface across all systems and while it will probably do this in an incremental fashion is not expect to deliver anything until at least 18 months into the new contracts.

This approach seems very wise to me, as I suspect 18 months is an optimistic  view of how long it will take to get to even a first version of a standard interface. Opening up what’s available now, particularly with some enhancement to the weaker systems, will be great stimulus to the market.

Work on the approach in phase 1 is going well, looks like it will substantially address the concerns raised in my last blog on this subject and enjoy broad support from both principal and subsidiary system suppliers and I don’t plan to say anything more about this here. What I want to do in the rest of the blog to look towards phase 2.

Point-to-point connections between principal and subsidiary system suppliers and accreditation on a similar per interface basis provides a viable option in the short-term but becomes increasing difficult as the number of subsidiary systems increases and becomes unsustainable when we look to moving the scope beyond GP systems. At this point we will need some form of intermediary bus such that all systems have only to conform and be accredited to the standards supported by the bus. It seems to me that while we might not absolutely need this in the immediate GPSoC context developing this as part of phase 2 would lay excellent foundations for the future.

I’m not a technical architect but it seem to me that it would be possible to use Enterprise Service Bus (ESB) technology to provide such a service (I would propose one of the existing health aware Open source ESBs) at it simplest the ESB would simply pass through interface requests looking no different to a third party supplier than an interaction directly with the principal systems. However, an ESB could do much more than this and its’ interposition would have many benefits:

  •  It could  off-load many functions from the principal supplier to make their lives easier requiring these functions to be implemented just once in the ESB rather than in each principal system e.g. authentication, identity management, access control, consent management IG, load balancing (to name a few.)
  •  It could protect principal suppliers from badly behaved applications and help in the arbitration of interface malfunctions (avoiding confrontation between principal and subsidiary system suppliers.)
  • It could  provide a transaction accounting platform that could support innovative business models (such as pay for use models) driving usage, better value and  more desirable and functional systems. The accounting platform could also provide a mechanism for charging the responsible party for compute resource consumed by interface users.
  • It could provide transformations and mappings between different technical and clinical content standards used in systems (making like easier for all participants) and facilitate incremental progress toward common standards.
  • It would provide infrastructure for interoperability beyond the scope of primary care.
  • Provide an access point for developers to other NHS systems (eg SPINE, EPS, C&B, Customer Service Platform) building on the good work done with the NHS Interoperability Toolkit ITK.

I plan to explore these ideas with the GPSoC Team and through my work with HANDI and Intellect and would welcomes others views.

More Information

More information about GPSoC and copies of many of the draft documents are available from the GPSoC web site.

What is an ESB?

There are a number of open source ESB with healthcare specific functionality that could be candidates for such a service:



Apache ServiceMix

More information about ITK is available at their web site

There is also relevant material on the HANDI and OpenGPSoC websites




GPSoC – We need independent accreditation of subsidiary products interfaces

I attended the second joint Intellect and DH workshop today to look at the plans for the GP Systems of Choice (GPSoC) procurement. These plans are at an advanced stage and the GPSoC Team told us they were hopeful of getting the necessary approvals in about a month to allow them to start the formal procurement process with a view to awarding contracts in November this year.

The GPSoC Team have done a great job, responding encouragingly to feedback from stakeholders, leaving us with just a few important things to work on:

  • Suppliers need to understand the importance of GPSoC not just for the supply of GP systems but for anyone who wants to sell apps, software and related service into GPs and CCGs (Woodcote Consulting has services that can help)
  • The GPSoC Team needs to ensure that GPSoC is accessible to current and future SMEs and micro-enterprises – Their suggestion of a G-Cloud like approach is on the right track.
  • All interested parties MUST review the draft documents presented at the workshop (now available on the GPSoC web site) and feed comments in directly to the GPSoC team or via Intellect.
  • We need to radically change the proposed accreditation process for subsidiary products to remove it from the hands of Principal System suppliers and place it in the hands of a trusted third party (this is the main focus of this blog and is discussed in more detail below.)

This is the second round of GPSoC and the proposals will, at their core, provide continuing funding for the GP systems that practices are already using. Although the arrangements are designed to encourage new entrants it seems pretty unlikely that anyone other than the four remaining existing incumbents will bid to provide full GP system functionality. Nonetheless the proposed new GPSoC arrangements will open up the market and encourage and enable Subsidiary suppliers who want to offer products and services to work alongside the Principal Systems.

Central to this is a requirement that GPSoC will place on Principal System suppliers to open up interfaces for use by Subsidiary systems. Initially this will build on the APIs which the Principal System suppliers current make available to a number of partners on a discretionary basis and in time will move towards standard interfaces across all systems. Most importantly the new arrangements will make the provision of open interfaces a contractual requirement removing the Principal System supplier’s discretion which, historically, some have used quite blatantly to obstruct potential competitors.

There is plenty of information about GPSoC on the GPSoC web site and I urge anyone with an interest in this area to review the draft documents and feed in comment to the GPSoC Team or via Intellect. If you want to sell IT, apps, software, analytics and related services in to the GP market it is going to be vital that you understand GPSoC and probably that you enter the procurement in at least one of the three proposed lots and it’s important you feed in your views to help ensure GPSoC will work for you.

My view is that the key challenge for GPSoC will be to make the proposed contractual commitment on Principal System suppliers to provide open interfaces a genuine reality on the ground. There are some unavoidable conflicts of interest between Principal and Subsidiary system suppliers and too many opportunities in the current proposals for the former to hinder a truly open and competitive market.

I think the only area where there are significant flaws in the GPSoC proposals are those related to the accreditation of  the interface between subsidiary products and principal systems, which I think are both too onerous (at least in some areas) and which give the Principal suppliers an inappropriately central role in accrediting what could potentially be competitors products creating an untenable conflict of interest.

I want to see this change and made the proposal at the meeting that the accreditation of subsidiary products interface with principal systems should be by an independent third party not the DH and certainly not the Principal System suppliers as is currently proposed. This proposal drew broad support and seems to me the way to proceed.

There are going to be many subsidiary products seeking accreditation and many of the suppliers of these will want support including technical advice and access to test environments before entering formal accreditation process. While it is almost certainly the case that the greatest expertise about their APIs currently rest with the Principal System suppliers they are for a number of reasons not the right people to carry out accreditation of subsidiary products:

  • It’s not their core business and even with goodwill they are unlikely to dedicate their best people and adequate priority to servicing third parties, particularly given the other pressure their technical resources will face
  • There are unavoidable conflicts of interest when accrediting competing products and even if Principal System suppliers avoid the temptation to act in their own interests they will never be free of the suspicion that they have – Indeed there are risks of inadequate rigour in the accreditation process as they seek to avoid accusations of anti-competitive behaviour
  • Subsidiary system suppliers will want to engage with a test environment well ahead of entering the formal accreditation process and in many cases will wish to do this under commercial confidentiality to avoid alerting competitors to their plans. I can’t imagine that Principal System suppliers will be able to create Chinese Walls in which others would have confidence nor are they likely to have the enthusiasm for providing the wider range of support services required beyond the core accreditation function.

It seem to me that to establish this facility, perhaps under the auspices of an organisation that already enjoys the trust of stakeholders, would not be particularly difficult. Doing so would require that the cooperation of Principal System suppliers is contractually secured, requiring them to provide copies of their system to create the test and accreditation platforms needed as well as documentation and assistance in training the staff of the new service, they would also need to be placed under an obligation to deal with ongoing technical queries from the third party to agreed service levels and to work with them to ensure the test environment’s interfaces were accurate replicas of their production environments.

Principal System suppliers will have legitimate concerns that subsidiary products accredited by the third party will operate correctly when transferred to their production environments and that they have the resources in place to meet the demands subsidiary products place on their systems and it will therefore be necessary to give Principal System suppliers some visibility of the accreditation pipeline and for the Subsidiary System suppliers to work with them and the third party to manage the transition to go-live.

Funding of the third party should also not be a problem with the simple reallocation of the funds identified for Principal System suppliers to carry out accreditation transferred to fund the core accreditation function of the third party, while the cost of optional services such as pre-accreditation support and access to test environments could reasonable be met by Subsidiary System suppliers.

There is detail work to be done but it seems to me this proposed approach has much merit. It:

  • Addresses the concerns of Subsidiary System suppliers that, for whatever reason, Principal System suppliers won’t provide a responsive and efficient accreditation service.
  • Frees Principal System suppliers of the burden of running the accreditation process and of any suspicion that they might abuse their position.
  • Provides a platform on which additional services and support can be more easily and appropriately made available to Subsidiary System suppliers to encourage innovation.
  • Protects the commercial confidentiality of Subsidiary System suppliers in the pre-accreditation phase.
  • Provides the foundations on which further intermediary services might be developed supporting a move towards common interface standards.

I’d welcome views from others about my proposal and would be delighted to talk to anyone who wants to know how Woodcote Consulting can help them make the most of GPSoC.

A Paperless NHS

Given the usual scant regard to the commonly accepted meaning of words that seems to be the norm in the NHS – “Paperless” is something that we now have in the majority of general practices and that many have had for some years and I’m really enthusiastic about the desire from the centre to drag the rest of the NHS into the Digital Age, but am really concerned that the initiative is being driven by a leadership who are, to be frank, clueless.

Firstly, the focus is wrong – Creating electronic records and/or removing paper, desirable as these may be, should not be the objective. The objective should to use technology to support and coordinate the processes of care so that the patient sees a integrated service that delivers greater convenience and quality.

This inevitably means more digital services, and will result in the creation of electronic records and the removal of paper from many processes, but in a way where these changes support process improvement. This is what happened in general practice – Processes were digitised one-by-one  and the data needed to support this digitisation was stored in electronic records. Over time these records became comprehensive and GP practices have become “paperlite”  this approach gave quick wins and avoided the risk of suddenly trying to go to fully electronic records. See Lessons from GP Computing

Secondly, we don’t have the infrastructure. Already nurses and junior doctors fight over ward terminals and the COWS (Computers on Wheels) for access to IT systems and when they finally rest a keyboard from colleagues typically find themselves  using obsolete hardware, operating systems and browsers accessing poorly integrated multiple  systems over inadequate networks. We need to address the infrastructure issues before we can go paperless (or lite). Every health and care professional needs their own device connected with ubiquitous LAN (WiFi) and WAN(3/4G) across the whole NHS estate and out into the community for those realtors. A paperless NHS without the infrastructure to support it will be worse than the current paper based system.

I’m all for putting pressure on NHS Trust to embrace a digital future and have some sympathy with the approach attributed to Richard Nixon: “When you have them by the short and curlies their hearts and minds will follow”. However, to secure the benefits that I believe are possible from the digitisation of the NHS we do have to win the hearts and minds of frontline staff and I don’t think this will be achieved by exhortations to do the impossible which will end up with ill-considered and poorly implement EPR systems  running on wholly inadequate infrastructure damaging morale and undermining patient care.

Creating a truly digital NHS requires careful design involving the public, patients, health and care professionals and digital engineers working together to create digital services to deliver truly holistic care. It requires infrastructure that is fit for purpose and needs the support of a health IT ecosystem that ensures all of the components play nicely together. See the HANDI Vision and the work of OpenGPSoC for more about what this ecosystem might look like.

I’m a firm believer that it is only by using information and information systems in innovative ways, both to support the way we directly deliver services and through analytics to effectively target and evaluate what we do, that we can hope to meet the challenges that the NHS and healthcare systems across the globe face. Headline political targets like  “a Paperless NHS” have their place in stimulating debate, but unless they are followed by meaningful action from those who have sound insight in to how digitisation might transform the way we deliver care and involve the public and patients in the process are little more than an distraction.

The Commissioning Board should focus on the Commissioning of care (both directly and through CCGs) and making sure that personal and organisational incentives for all the actors in the system are aligned with the imperative to deliver better quality more convenient services for less. They also need to ensure that the information flows required to support individual care and monitor the performance of the system as a whole are available by making these the basis on which providers are paid for their services. I can’t see how providers can achieve the transformation required without embracing IT, widespread digitisation and social media, but hold them to account for their outputs, not how they achieve them.  By setting ill-consider targets about a paperless NHS and EPRs the Commissioning Board is just giving providers excuses to fail at their core task.

Theses issues were discussed on the  #CCIO tweetchat on Wed 20 Feb  7-8pm  For the best bits and full transcript can be found here 

There are also themes here to pick up at the PHCSG UnConference on 6th June

Patient record access – A spur to innovation

I’ve been involved in one of the working groups which are part of the RCGP-Led Online Patient Access Project,  which has been funded by DH to help deliver on the Government’s promise to deliver online access for all to their GP records and a range of associated transactional services by 2015. As part of this work I attended a meeting tyesterday (25 Oct 2012) between the project and interested suppliers from the Intellect Healthcare Group.

This was an open meeting with selected press present so unlike other parts of my work with the project I’m free to talk about what went on. However, it’s not the core subject of the meeting I want to talk about, but how the meeting illustrated the potential that is unleashed when you start talking about opening up systems.

First some background. GP record access has been pioneered for some years by EMIS  working with Paers  and delivers full read-only record access along with support for transactional services (appointment booking, repeat medication requests, secure communication). So far only a handful of pioneers have turned on full record access while many more have opened up one or more transactional service. The two other significant GP suppliers also now offer transactional services and have full record access ready to go and it seems likely that the RCGP project, combined with sticks and carrots from Government , aimed at GPs, along with demand from patients will mean that the services become available to all GP practices during 2013, although I think it remains to be seen how many practices will opt to grant  full online record access and how strongly they will promote the services they choose to offer to their patients.

Government, however are not content with just getting basic services delivered by the incumbent GP suppliers, but have much more exciting plans to see core systems opened up to encourage third parties to develop a range of innovative services that will deliver record access and transactional services in a variety of ways.  There is an expectation that some of these new services will simply provide a slicker interface or access in ways more suited to particular patient groups while others will integrate patient record access in to products with broader scope (particular as part of services designed to help patient and their informal care networks manage long-term conditions) and finally there is a hope that some new things will emerge that those of us currently involved have not yet imagined.

From today’s meeting it seem to me that hopes for innovation are likely to met or exceeded if Government can get the technical stuff right and tweak incentives to ensure an opportunity for viable business models is created.

My reasons for reaching the opportunistic conclusion are based on what infer from examining the list of attendees and what was said at the meeting.  There were about 35 companies represented at the meeting including the large and small, many were primarily IT companies but a significant number were organisations offering a range of clinical and health management service. Interestingly, only one of the incumbent GP suppliers was represented and they had little to say.

The focus from the companies present was unsurprisingly on what might be available to them as a result of the records access project, but it was clear that they were also interested in the broader opportunities for innovation created for them by the opening up of systems, the data they contain and the transactions they manage.

The potential here is massive and I think this was not lost on the officials present from the Dept. of Health and the NHS Commissioning Board. I hope they will take the buzz from the meeting back to their masters as evidence that their commitment to open-data and open-systems does have the transformational power they hope for.

However, as you might expect there is a caveat. Catalysing the transformation requires more than just opening systems and data it requires action and investment to create an technical, cultural and contractual environment  which will allow the reaction to proceed at pace. Technically, this is about infrastructure and infrastructural  services (like identity management) and the right approach to standards see my blog: Standards are a barrier to innovation Culturally it’s about selling the benefits of transparency and managing legitimate fears about the “Daily Mail” effect. Commercially it’s about addressing procurement issues and creating an ecosystem in which sustainable business models can be built around openness.

There is much in what’s happening to encourage us but Government needs to act to ensure that the excitement and innovation they have created delivers sustainable benefit.


GP System Change

As the current arrangements for the supply of GP systems under the NPfIT and GPSoC come to an end GPs maybe thinking about a potential system change. In particular some emerging CCGs are promoting system change to achieve a single system on their patch, but my advice would be to wait and I say this for two reasons.

Firstly, because of the pain involved in a system change and secondly because changes in the way IT is delivered as a result of the app revolution, probably removes many of the reasons for a change.

Most GP practices have been computerised long enough to have experienced at least one major system change and will know how painful it can be. I wrote a document in 2004 which included a section about system change and most of what I said then remains as true to day as it was then (click here for an edited extract). A change, even to something clearly better, is likely to result in a period of at least six months plus before a practice gets back to where it started and I would argue that for users of any one of the current GP systems there are not any alternatives on offer that are “clearly better”. Any practice thinking of changing needs to think carefully if the benefit of any change justifies the costs and loss of revenue which inevitable flow from a such a change and what the alternatives to such a bruising experience might be.

The app revolution promises to offer a software from third parties that will extend and enhance existing systems without the need to replace the underlying core system, just with the use of a Software development outsourcing. These apps will offer new functionality along with improved user interfaces and an enhanced user experience on top of existing systems as well to improve all the system itself and all its variables, this will also help you increase the performance and quality resolution on your screen that will help you have a better software movement and even improve your gaming services, you can Review Here for more information about great game websites were you can try this one out.

At the same time as the revolution at the user interface overwhelming Government commitment to open systems and open data, restated in the recently published NHS Information Strategy, along with new technologies to integrate data at the back-end means that the drive towards a single system approach to integration at the level of a care community, that is often cited a the reason for system change, is no longer valid.

Better Integration of care and the more effective sharing of data is central to meeting the challenges faced by the NHS, but the way to achieve this at the level of a care community is no longer through lowest common denominator single system (if it ever was?) Historically many PCTs have pushed single systems solutions and this view remains disturbingly present with some of the emerging CCGs. I suggest that those who still see this approach look again and that individual GP practice resist the pressure to take the pain of a system change for the greater good, when there are actually better ways to make the gain without the pain.

Most GP are reasonably well served by their current system and there are new was to meet GPs IT needs just around the corner so my advice is to sit tight – Now is not the time to change.

Edited extract of relevant section  from my 2004 document is reproduced below. The full document is available here, although much of it is only of historical interest.

Most GPs have experienced a significant upgrade or replacement and know that this involves considerable work and no little pain: re-training staff, re- engineering or re-implementing business process and converting data. They also know that hurried, poorly planned or poorly implemented upgrades can be a disaster.

GPs have large amounts of data relevant to current patient care. Data conversions as part of an upgrade have been problematic in the past, but cannot be avoided. The expertise exists to build data conversion tools and processes that are safe and effective, but individual conversions will require significant work by practices in preparation and data validation that cannot be done by others. GPs will want assurance that a clinically and medico- legally adequate data transfer will be made to new systems, and are particularly concerned that this may not be the case.

Any upgrade will require a GP Practice to make a considerable investment in time and effort if it is to be successful, and it must be accepted that initially a new system will do less and do it less well than the system it replaces.

The impact on “utility” of a system upgrade is illustrated by the graph below.


Established  systems  reach  a  point  (their  “utility  ceiling”)  at which  their original design and technological foundations make it increasing difficult to add new facilities, take advantage of new technologies or implement new ways of working.

Irrespective of how good a new system is at the point of upgrade there is an inevitable loss of utility (L) as users learn to work with a new system, retrain staff and re-implement business processes.  In a highly IT dependent environment like general practice this loss will be material and at worst can result in the practice becoming dysfunctional.

In a well judged and managed upgrade utility recovers and users eventually find themselves back at their starting point. Previous experience tells us that for a well managed upgrade the recovery time (R) is 6-18 months

Finally, as systems mature and users learn to exploit them; utility grows to levels not reachable with the old system until the new system too reaches full maturity and a new utility ceiling. It is this gain (G) that justifies the upgrade.

If GPs are to be persuaded of the need to upgrade they will need to be convinced that the quality of the new system and upgrade process is such that the loss at the point of upgrade and recovery time are minimised and survivable, and that the new system has proven potential to provide an eventually substantial utility gain. An honest approach that sets expectations appropriately will gain support whereas unrealistic promises will result in strife.

GP practices will accept some pain in order to promote the greater good of the NHS and participate in a programme designed to lay foundations for the next generation of NHS IT which does not immediately bring them benefit. However, such altruism has strict limits and GP practices need to be persuaded of the need to upgrade primarily in terms of the direct benefits to themselves.

NHS Hack Day – Making an Old Man Happy

I’ve been fortunate enough to fall in with some of those young clinicians and developers organising NHS Hack Day (actually two days 26/27 May 2012 in Central London) and I think this is one of the most exciting things to happen in Health IT for many years. It also fit well with my latest not-for-profit venture about which more soon.

This free event is now “sold out” (they are trying to get more space at their venue) but you can still participate by joining “nhshackday” at

The energy and enthusiasm of this group reminds me of the early days of GP Computing in the 1980’s and I think they might give a spur in the Acute sector like that of the early pioneers in  UK General Practice.

UK GP Computing was the first widespread application of IT at the point-of-care and retains a position of global leadership. Today over 99% of practices have been fully computerised for more than 10 years, most practices operate” paper light” and most mid-career GPs have never known general practice without a computer.

Progress in the Acute sector has been disappointing, but I think those behind NHS Hack Day are about to change this and I want to encourage them and suggest they take heart and learn lessons from what happen in GP land 30 years ago.

The reason for success in General Practice and the lack of similar progress in the acute sector are many (see: ) for more. But at the heart of this was the collaboration that emerged between young GPs and techies in the early 1980’s from which all of those companies that have shaped the GP System market emerged.

These young people were fascinated by the power of the early PCs (Apple II, PET, TRS80) and a raft of long forgotten micro-processor based mini-computers which meant a GP practice could afford a computer. They saw opportunities to improve care, build business but above all have some fun. The clinicians learnt a lot about the technology (programming their Sinclair’s, BBC Micros etc – Parallels with apps, open source and the RaspberryPi ?) and the techies developed a deep understanding of primary health care which they lived and breathed with their clinical mates. From the shared understand and respect came some amazing things.

Many of these people are now in positions of leadership in the clinical professions, academia,  industry and the global health informatics community, they haven’t all found out about NHS Hack Day yet, but those that have are much encouraged by what we see what is  (primarily) our children’s generation doing.

As ever, this new generation will need to ignore a lot of our advice in order to make progress (as we did before them) but there are things to be  learnt from our history and there is much we will try and do to support you.

We wish you well and stand ready to try and help.

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 )

•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

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 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.

Analytics – Whose data is it anyway?

There are a growing number of techniques which might be described by the term “health analytics” which are able to use patient data (generally pseudonymised) for a range of valuable purposes which can help identify opportunities to delver more appropriate, better quality and more cost-effective care. With the challenges healthcare faces using information more intelligently is not optional – We need to do all we can to facilitate the development and application of better health analytics.

There are many governance issues associated with using data for these purposes, which are not the topic of this piece, but suffice it to say there are real concerns, but concerns which can be addressed to ensure patient’s privacy and wishes are respected.

The application of analytics typically requires the extraction and linkage of data from more than one source and this requires the corporation of application designers and those organisations that host systems to facilitate access and the extraction of data. Designers and hosting companies (often one and the same) have some legitimate concerns with regard to risks to the integrity of their systems and operational impact of data extraction, but I’m concerned that some are less cooperative than they might be , sometimes to the point of being obstructive, going well beyond what can be justified by their legitimate concerms. My particular experience is in primary care, where access to practice hosted systems has generally be possible where the practice wish it, but with the growth of hosted systems control seems to be shifting to system suppliers.

It seems to me that it is the customer (more specifically the customer’s Data Controller or Caldicott Guardian) who should be in control of who is allowed to extract data from systems after satisfying themselves of the appropriateness of the data extract and that all patient privacy and any other governance issues have been appropriately addressed. Purchases of IT system should ensure that suppliers are contractually required to provide facilities to support approved extractions in a timely manner, but should understand that this may have an impact on the cost and/or service levels in a hosted environment. The basic facilities required should be no more than those any adequate system should provide as part of its standard reporting tools, but some of the requirements particular to analytics purposes (e.g. pseudonymisation, or the ability to run standard queries like HQL (Miquest, GPES)) might reasonably require additional facilities which might attract additional charges.

The requirements of health analytics are sometimes better met by third-party tools rather than the native reporting tools of individual systems and purchasers of systems should ensure that API’s are available that will allow third-party tools to connect efficiently.
Many suppliers see commercial opportunities in the exploitation of data in customer systems that they supply or host and I have no problem with their exploiting such opportunities subject to the following caveats:

• In general patient’s should be the final arbiter of how their data is used for secondary purposes. They should be made aware of such uses and have an opportunity to object (as required by both the NHS Code of Confidentiality and GMC Guidance.

• Their customers, not the suppliers should be in full control of how data in systems is used and they are responsible for ensuring such use is appropriate and respects patient’s confidentiality and wishes and meet other governance requirements.

• While supplier s may work with their customers to develop services based on secondary uses of data, they should not seek to restrict customers from working with any other party they may choose.
The actions of some suppliers to create artificial technical barriers to data extraction (e.g. by imposing arbitrary limits on the number or records that can be extracted or refusal to make available appropriate APIs to allow third parties to connect to their systems) are unacceptable and customers should ensure that contracts exclude such anti-competitive behaviour.

Opening up information to health analysis and scrutiny to all those with an interest in doing so is central to Government policy and the key to identifying opportunities to delver more appropriate, better quality and more cost-effective care. Subject always to respect for patient’s wishes and privacy, other barriers to access to information need to be swept aside.

(Declaration of interest. My company, Woodcote Consulting has a number of clients who we advise in relation to the extraction of data for analytic purposes.)