This article first appeared on 25.8.15 on digitalhealth.net.
I read several books over my summer holiday. Several touched on the history of the personal computing industry.
A couple commented that even huge, entrenched monopolies can make mistakes and end up losing their status. IBM made the decision to use MS-DOS and let Microsoft licence it to others; so IBM seeded control of the desktop to Microsoft.
Then, Microsoft arguably lost the personal computer battle to smartphone operating systems, such as Android. In another field, Disney lost out to Pixar (and had to buy it).
Dinosaur, meet extinction event
The books didn’t have one theory as to why this happened. Most discussed the idea that large organisations are unable to change quickly and adapt to new technologies and customer needs: the dinosaur meets evolutionary event theory.
However, they got confusing when they tried to discuss how large organisations could look out for the signs of change that might precede such an event.
A couple seemed to back the idea that there’s no point doing market research at all: the punters don’t know what they want until we give it to them approach.
I suspect this is great if, ultimately, it turns out that you are a great visionary and the punters do all rush out and buy what you offer them. But, as a general rule, it would seem sensible to listen to what the customer wants and then do that.
Pleasing the piper and the users
Programmers already run in monthly sprints under something called ‘agile’ development. These sprints should be focused on customer need and should be rigorously a/b split tested: in other words, random sections of your users get alternative upgrades to try and then you go with the one that works.
One of the books I read is a fairly well known publication on ‘lean’ start-ups. It argued that through the use of such testing, and the clever use of metrics, you can grow your product.
It was a good book, but it didn’t, to my mind, explain how to get around a problem that faces healthcare IT – namely that the user of your software and the person paying for it may be two different entities.
Take primary care computing. Who are its users? Well, let’s say GP practices and their patients. What are their goals? Well, let’s say they are good care. What does that mean, in IT terms?
Well, lets say some of that is good screening tools, good case management tools, good diagnostic tools, good reporting tools, some auditing tools and some tools that maximise efficiency.
Primary care computing is paid for centrally. Are paymaster goals aligned with user goals? You would hope so, but it doesn’t often feel that way.
What we get are “let’s monitor what the GPs are doing” tools, “let’s introduce politically driven ideas that don’t really affect patient care” tools. This disharmony causes a problem. Does it lead to a situation where the existing set-up could be broken?
Is that a meteor?
Digital Health News recently reported that one of the co-founders of Emis, David Stables, has set up a charity, Endeavor Health, to try and provide integration technologies to the NHS and reduce the commercial barriers to data sharing.
Potentially, this is a very interesting development. Could it bring about my long held wish for the front-end market place to be broken up, so that companies compete on their usefulness to me, the user?
I have a specific, concrete example of where existing suppliers are missing out on user needs. GPs are being pushed to federate. To work together in ever bigger groups. If not in one, big super practice then certainly in groups of practices sharing some of their work.
Some of the simple ways to start doing this might be to share Read coding, typing, prescriptions work, reception and so forth, so any patient could be seen at any location in the group by any nurse or doctor.
Let’s imagine a group of six practices wanting to work together. They want to centralise their telephone answering. They want to put all their typists in one room, all their Read coders in one room.
Work to common standards, train people together. Get better skill mix. Perhaps even save some money on temps and recruitment because they have better trained and more motivated staff.
Or, let’s say they want to amalgamate their nursing teams to allow for career development, to allow people to learn new skills, and to spread those skills across a wider net.
With existing IT systems, all this is very difficult, if not actually impossible. There are no tools to link patients to spokes or hubs or nodes or whatever topology is used. Once you’ve merged the database, it’s merged. After that, looking at the work of individual teams is hard without conducting a lot of custom-built searches.
Thinking the unthinkable
Locally we have some GPs thinking the unthinkable; let’s merge but do it in stages, trying to realise the benefits along the way.
Most of the blocks we are facing are related to IT. Emis Web has some enterprise features, but they are clunky and not that flexible. Then there’s PCTI’s Docman. All our local practices have used Docman for years, but it just doesn’t seem to play in an enterprise vision.
If we have managed to get remote access set-up, I can use Emis to see the records of a patient in another surgery. I can do a consultation and have the original surgery see my notes. Can I see any of the letters? No.
Remote access doesn’t work for Docman. The best we can do is a bodge; use remote access to get onto a desktop on a surgery machine and use its viewers. It’s a pain.
We are a wave two Prime Minister’s Challenge Fund site, tasked with finding ways to open up access to patients. We are live with practices opening early and late during the week and we are in the process of setting up a hub for the weekend.
We have practices interested. We have GPs willing to work. We just can’t see the notes for patients who aren’t registered at the surgery very well. And the letters are pretty much missing entirely.
I’ve told the PMCF people all of this until I’m fed up of telling them. Despite their endless offers of ‘help’, nobody has got back to me. As for Emis and PCTI: they are accredited partners. They use the API. They need a solution asap.
One of the books I read on my holiday was about Steve Jobs, the founder of Apple. Apparently, he had a revolutionary moment when he understood that the future of computing – post Apple II – lay in networking not in unconnected machines.
I think the future of GP computing is in networking practices at the back-end and in a shake-up of the market at the front-end. Incumbents need to realise this; or I’m going to go with the product that does.