Category Archives: GPSoC

NHS VistA – An Update

[Update with additional Links ahead of NHS England/Intellect workshop on 8 July]

There is growing support for the production of a NHS version of the VistA the US open source EPR used by the US Veterans Administration and more recently by a number of health systems outside of the US.

I’m a tremendous fan of what the VA have achieved and believe we have lots to learn from VistA, but on balance I don’t think producing an “NHS VistA” is a good thing. Most of my reasoning for this is laid out in my earlier blog  (if you have not read this read it first),  in this I remain sitting on the fence and I now think it is time to come off firmly on the negative side and I want to explain why.

The NHS VA has achieved an amazing transformation from “basket case” to “best care anywhere”  VistA was a necessary but far from sufficient driver of this  transformation, which was down to truly inspirational leadership and a broader system redesign – Read Phillip Longman’s book “Best Care Anywhere”

The VA had reach rock bottom (loosing patients and eventually finding them dead in the hospital grounds). The NHS has it failings but is far from a “basket case” sitting as it does higher on the global healthcare quality/value league tables.

I’ve had a lot of experience of the localisations challenges associated with bring US software to the UK. These are massive and always wildly underestimated, Plus you need the right amount of money, but there is a solution to that, have a peek here. Who have delved in the source code will confirm it is of Byzantium complexity Maybe not a problem if you just have to tweek it and can wrap it in a modern API to shield most developers from the spaghetti, but not an attractive option given the localisation challenge which will force substantial changes to the core.

My view is that rather than invest in producing an NHS VistA that our resources would be more effectively deployed on developing alternative open source approaches based on current thinking about health ecosystem architectures and contemporary tools and in particularly those that already have a foothold in the NHS.

What we need to take for the VA and VistA is not the VistA code, but the approach. In particular, we need to understand the importance of inspirational clinical leadership, the critical importance of getting frontline engagement in the development of healthcare software and the role of an open ecosystem in creating this engagement.

In my view an open-ecosystem has to take an open-source based approach to providing its key infrastructural components to avoid vendor lock-in through IPR ownership, but beyond this both proprietary and open-source components have a role to play and the choice should be left to end users and the patients they serve.

As well as my original blog on VistA other post to my blog have relevance to these discussions including:

Digital Healthcare – Making the most of NHS IPR

Time for Zero-Tolerance

SPINE 2 – A Game Changer for NHS IT

For some more background see the following:

Campaign for NHS VistA

World VistA 


VistA Modernisation Report – Report commissioned by the VA on Modernisation options for VistA

A long report but this recommendation struck me:

“VistA is currently deployed to a small community of public, private and international users outside of the VA. However, because it is very difficult to operate and expensive to modify it has not had a much wider adoption. We recommend that VistA be used as a functional specification and be completely reengineered within the VistA 2.0 Open-source, Open-standards Ecosystem as recommended by this working group so that a much wider community can adopt and extend it more readily.” – Their emphasis not mine.

Not sure where this led but some work seems to have been commissioned with  Harris Healthcare

More here: VA looking for help to set up governance for open source VistA

VistA as an EHR System Core – Interesting paper by Dr Mike O’Neill from the VA
This is the proposal submitted by the US Department of Veterans Affairs (VA) to the Department of Defense in response to the Request for Information for an EHR that can replace the existing DoD EHRs. – DoD eventually concluded to go for a competitive procurement that may include VistA alongside proprietary solutions.

Other sites where I have also made a contribution are worth a look




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.