HSCIC/NHS Digital, GPSoC, APIs & Start-ups!

Hello everyone. I’m a GP registrar and have been trying to build an app for a some GP practices for a while now. I had no idea how a simple idea could be near impossible to execute due to the convoluted pathways currently in place.

I just wanted to start a thread and talk about what I have learnt so far with a quick summary. If anyone has anything to add then please join in!

PART I - Basic Definitions

GPSoC = GP Systems of Choice.

GPSoC are an organisation that help GP surgeries have he best technology to support them. It is hoped that this can be accomplished by a “Common Interface Mechanism” for GP IT systems integration.

Common Interface Mechanisms = is a mechanism that would allow separate systems to integrate and share information. This would allow integration between Principle Clinical Systems (such as Emis Web, TPP SystmOne etc) with Subsidiary modules such as specialist apps and third party products.

GPSoC is also meant to hold principle software suppliers to account.

PART II – Different IT Products

There are three different categories of IT that GPSoC recognise.

  1. Lot 1 – Core functionality products for a modern paper light GP practice. E.g appointment booking tools
  2. Lot 2 – Products which support the GP practice hardware and medical devices
  3. Lot 3 – Help GP practices to share information with other health care providers

PART III – Pairing Integration

Suppliers of clinical systems to General Practice are required to provide integration capability via an interface mechanism/mechanisms. The interface mechanism enables separate third party systems to access demographic and clinical data held within the system.

There are two scenarios for the use of this capability:

  1. To support products, chosen by the practice and used within the practice, that need to integrate with principal clinical systems
  2. To support the use of internet facing tools for patients (including record access and transactional services)

This is meant to look like this:

PART IV – The Process

So, the process seems rather long and convoluted. If you want to get any kind of “mechanism” to allow interoperability between your app and the GP IT providers software and then want to roll anything out which can be procured by the CCG then you have to go through a five step process:

  1. Fill out PIQ (Pairing Integration Qualification) Entry Form. This involves the following:
  2. Clearly describing the service and functional capabilities
  3. Clearly describing the technical architecture
  4. Show that the technical architecture is up the best practice and technological standards
  5. Show that the technology has a considered approach to data storage
  6. Clearly describing the deployment method
  7. Clearly describing the service management and support arrangements
  8. Clearly describing the method of delivery and associated training
  9. Provide suitable information to support alignment to the NHS information strategy
  10. Provide suitable evidence to support provisional viability
  11. Provide suitable evidence regarding the ease of achieving a Pairing Integration
  12. Clearly describes the expected impact of the offered service on an interface mechanis
  13. Clearly describes identified risks and issues and the proposed mitigation actions
  14. PIQ Initiation
  15. PIQ Design Build and Test
  16. PIA (Pairing integration assurance) – Development and test
  17. PIA – Development First of Type

After the above five steps you get the full roll out approval.

Part V – Discussion

The above information is a rough overview of how to get APIs and get your idea on a roll. After having discussions with people who work at both TPP and Emis, it seems that this really is the only way to get anything going.

I am booked to have a phone call with someone from TPP on Monday to see if I can get some more information and how to make sure my application doesn’t fail. I have also contacted HSCIC/NHS digital and am booked to speak with someone from there as well.

It seems frustratingly hard to get anywhere. I do not know how small start-ups/bootstrapped companies can even get started! It seems like the only companies that are getting anywhere with all of this are large established corporations. There are only 25 or so companies that have managed to get anywhere with all of this in the last two years!

Also, as if the above process wasn’t convoluted enough, in reality the process is even more difficult. A CEO of one tech company mentioned how hard it has been and how the API process has delayed them immensely: http://www.digitalhealth.net/digital_patient/47749/iplato-launches-mygp-appointments-app-as-api-talks-continue

This is another interesting read: http://www.digitalhealth.net/news/47510//patient-facing-integrations-with-gp-systems-run-late

It talks about how all the deadlines are being missed and how only two companies have managed to get Full Roll out Approval since GPSoC started!

Does anyone believe that a start up company could actually compete and exist in this environment? It seems like the environment is exactly the opposite of what was being aimed for with GPSoC.

Thoughts anyone?

1 Like

We’ve had similar issues in secondary care and one of the common approaches is to use middleware which deals with Part IV. The middleware supplier deals with a lot of the paperwork and will also simplify the API (National interfaces can be quite complex for simple problems).

For primary care interfaces we use the MIG (http://www.healthcaregateway.co.uk/) and Intersystems Healthshare/TIE (Spine and child protection system access). From what I’ve seen of Endeavour Health (http://www.endeavourhealth.org/), it should be possible to use that. We’ve also gone directly to EMIS via our TIE.

Another option would be to work with other app providers and build your own middleware system which you take through ‘The Process’ as a group. The middleware can also be used cope with differences between supplier systems or transforming the data to/from different formats. Open source examples of middleware include Apache Camel (http://camel.apache.org/), Apache ServiceMix (http://servicemix.apache.org/), Mule and Mirth. Some of these can be easily scaled up to meet demand.


Thank you so much for your insight! It is odd that no one that I have spoken to from Emis or TPP had sign posted that these middleware suppliers even existed!

Hopefully I can finally move forward with my project! :slight_smile:

Google for Digital Health Platform NHS, and you’ll find there are things available to help you out with all this.

This is amazing!

I can’t tell you how many hours I’ve spent trying to find out/get APIs.

I’m truly grateful! :grinning:

Hi Rakeeb,

Lots of people agree it’s difficult for small startups and app developers to make headway in the current NHS environment. Early ideas are easy to implement given current web technologies, but subsequent scale and compliance are very hard to achieve.

HANDI may have some useful resources for you.

Also, all being well, Operon may have some useful, open standards ‘pre-cooked’ resources for you to hook into (such as authentication / SSO / audit trail / terminology / patient index / structured and unstructured data repositories) as it develops.

The first (basic) N3-hosted version of its platform is due later this year.


Hi Mark,

Thanks for your reply.

I completely agree that it’s very hard for start ups in the NHS. I’m actually part of the “clinical entrepreneurship programme” ran by NHS Innovation. They are trying to make the NHS more of an accommodating environment for start ups, but it is still incredibly hard, no matter how many contacts you have.

I have to say that the clinicians themselves are often the problem as a lot of people have the “that’s not how we do things around here” mentality, but this is compounded by certain companies who seem to have a monopoly in certain areas and have erected false barriers to entry.

Thanks again for your help! I will be looking through all these links this evening! :relaxed:

Hi, currently I would say its a hard process from scratch as others have said. We have been in the GPSoC interfacing programme for over 1.5 years and nearing the point where we can test with TPP and EMIS. The GP Connect programme is your best bet as it will provide a FHIR interface across all GP Systems that are lot 1 providers. I think it will be a couple of years before GP Connect provides real usable data.

We have built our own middleware working with MESH/DTS used mainly to deliver document files to GP Practices plus FHIR. Currently working on mini-SPINE implementations too.

Mirth is a good place to look for a middleware engine. A lot of commercial offerings use this.

The #interopen initiative is also trying to speed up delivery of FHIR interfaces and includes the main GP system suppliers in Lot 1.

Good luck,


Have you used mirth with FHIR API’s?

I was wondering about it’s suitability with the move from HL7v2 messaging (where it has proved very useful) to the more web orientated HL7 FHIR (web2.0) world. The engine we use is missing a few features to support web2.0 and I gave up on it for detailed FHIR work. We are still using it but we are putting in Apache Camel where traditionally we would have found Mirth. Endeavour, MIG, Answer are also using Camel, the new spine uses related java products.

If you want to get up and running with FHIR, I’d suggest looking at http://hapifhir.io/ it provides a FHIR Server which supports most of the complex operations, 100% open source and scalable. You can literally be up and running within a few hours (if your familiar with a tomcat and MySql), maybe a day or two if not. I’ve done a few sample camel apps that work with HAPI FHIR and HAPI HL7v2 (which mirth uses) https://github.com/KevinMayfield/Jorvik
[Hopefully will have some examples of the FHIR interface we hope to have running at acute trusts in our region… soon (and within other timescales)]

Hi, we haven’t used Mirth in anger for FHIR. Will follow-up your links. Our FHIR implementation is currently based on our own gateway engine.


Hi Paul,

Does GP Connect allow patients to request repeat prescription ?

DO you recommend GP Connect is the only way to go forward if that is what we are building ?



Hi, sorry haven’t logged in for a while. I think it will do. Currently this has to be performed via the Patient Facing API. However, I wouldn’t go down that route as there is a long queue of companies waiting to get through the gate with the GP systems.