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.