Another view

The idea of breaking banks into their separate components is in the news at the moment.

Now, I’m not expert on banking, so I don’t really have an opinion on this. But it has made me think about the broader issue of whether one company should be allowed to try to do everything in its sector, or whether it should it be broken up if it gets too big.

One argument for size is that the profitable side of a company might keep a non-profitable side going in lean years; and there are numerous companies where only one part makes a profit, or where others are struggling to come good.

One argument for splitting is to introduce competition, especially when there will otherwise be a monopoly or a very limited choice of alternatives. We have experience of this happening, for instance BT being split into wholesale and retail.

Breaking up is hard to do

This leads me to our current GP suppliers. Should somebody be thinking about splitting them up?

For years now, they have been migrating practices onto the so-called ‘enterprise’ or ‘cloud’ version of their systems. And there are clear advantages to having one, big, scalable server in the sky to thousands of servers in every practice.

However, this does mean that companies that should be concentrating on delivering usability and functionality are spending a lot of their time delivering scalability, reliance, performance; and all the other server type stuff.

My understanding is that there are big IT companies out there that do nothing but run massive server farms. Are we happy that our GP clinical suppliers are as good at what they do as they are?

Or perhaps they already outsource to them. I don’t know. For the moment, I’m just raising the issue because it has an impact on who owns my data, and who controls my access to it.

Putting aside whether or not I agree with the idea of selling data to third parties, I find it interesting that the government is almost having to create a copy of the “data” in care.data, instead of being able to query the real data directly.

Separating data from systems

I remember an Emis National User Group conference at which a speaker on extracting data and analysing it in Excel fielded a question from an independent data analyst in the audience.

He’d come along to see if there was any work in the health marketplace, and he asked why, if you owned the data, the database and the hardware it was running on, you couldn’t you just run a SQL query on it.

He suggested this would enable it to be analysed in all sorts of sophisticated packages that he knew about.

The speaker put him off by saying that the system supplier wouldn’t allow, and we should be grateful we could get some data into Excel as Miquest – a national tool for extracting information from GP computer systems using a common query language – was “pants”.

EHI Primary Care reported recently that Emis has launched an EPR Viewer that allows an authorised viewer access to any patient’s record, no matter which surgery they are registered with.

This made me think, first, that this should be easy as all the data is in one place; all you have to do is validate access and then display it.

And, second, does that mean I can have a query tool that allows me to query the master database for any practice/patient that I have permission for, without having to go through a third party that has traditionally charged a lot of money for data extractions.

Ten practices, one access point?

My clinical commissioning group might be really interested in that. I’m currently working with a provider federation of practices and we have been looking at the usual stuff; referrals, diagnostics…

But getting the data to do this isn’t easy. Secondary Uses Service/Hospital Episodes Statistics data is rubbish. I want to analyse the actual practice data.

I have their permission, but I don’t want to have to drive round ten practices or disturb ten practice managers every time I need to pull up some more data.

So, going back to my banking analogy, should we be splitting the data from the system that records and houses it, and letting any system access the data? Do we need some competition? Do we break the monopoly?

GPSoC2: another solution?

I was thinking about all this when a contact from an IT company for which my surgery has done some beta testing rang up to update me on where it had got to.

He was very excited about the new GP Systems of Choice, or GPSoC2. I have to admit this has passed me by a little. But my understanding is all the GP suppliers’ contracts are up for renegotiation and the powers-that-be want some changes.

They are not planning to break up the existing IT companies. But they are demanding a common, consistent application programming interface framework that all future suppliers will have to sign up to.

To begin with, this will cover basic functionality. But, in theory, it should be rich enough to allow third parties to interact with any system, encouraging the development of a richer third party market.

There is more to GPSoC2. I gather that it will come with different levels of approval, with some levels of software being centrally funded and others having to be bought locally. That might complicate things; but it should also focus peoples’ minds on what they really want and value.

My contact also mentioned that the team behind Choose and Book2 is thinking of doing the same, and demanding a rich API. If this is the case, I welcome it. I've always hated the user experience of C&B.

Allowing people to access the slots, but presenting the information and enabling them to interact with it in different ways is, I think, the way forward.

Dr Neil Paul

Dr Neil Paul is a full time partner at Sandbach GPs; a large (22,000 patient) practice in semi-rural Cheshire. He is also one of the directors of 4GPs Ltd. Dr Paul has been involved in primary care IT and health service management for more than years in various roles, including PEC member and urgent care lead. In his spare time, he writes medical iPhone software and is a keen photographer.