The new GP Systems of Choice contract could force all GP system suppliers to open their Application Programme Interfaces to third party suppliers.
The idea would coincide with the Government ICT strategy, which states: “The opening up of APIs is part of the government’s overall approach to open ICT and user centred digital services."
Intellect head of healthcare Jon Lindberg said he understands the idea is being discussed internally with the GPSoC team and board.
He hoped it would help open up the market and allow “quick and innovative solutions” to be developed and added on as demand and requirements develop.
However, he said there are a number of unanswered questions around commercially viable models for both third party suppliers and GP system suppliers.
“How do they (GP suppliers) manage these third party suppliers? Who ensures they meet all relevant standards on security, safety, data?” he asked.
Lindberg said Intellect is looking to host an all-day supplier market engagement workshop in December with industry and the GPSoC team to discuss their initial proposal and to invite industry feedback.
Healthcare App Network for Development and Innovation founder Ewan Davis said open APIs are essential to encourage third party developers - particularly app developers - to provide alternative ways for people to access their health records and the digital services that are part of records access.
The impact of a GPSoC contract change would depend on the extent to which suppliers comply and the “extent to which the centre holds them to the fire to do so.”
While all GP system suppliers offer access to their APIs, their commercial terms are sometimes considered “too onerous” by third parties.
This must be balanced against GP suppliers' legitimate concerns about protecting their systems and intellectual property and the need to fund extra capacity to support other applications, he explained.
Dr Paul Cundy, joint chairman of the BMA and RCGP's joint IT committee, said that various suppliers already have API arrangements with third parties.
“If this is true it’s good news,” he added.
GP system suppliers told eHealth Insider the change would expand choice for customers, but said technical issues will have to be worked out first.
EMIS Group CEO Sean Riddell said: “With the relevant safeguards and monitoring in place, mandatory APIs available on all clinical software used in the NHS can only be of benefit to both suppliers and customers - supporting innovation and improved patient care.”
Chris Netherton, managing director of Microtest, said the company would welcome the change as a “sensible addition to the contract.”
“As with all things, Quality Assurance, Support and Service level Agreements with third Party Application providers are key, to prevent third Party Applications negatively impacting on the performance and reliability of clinical systems,” he added.
INPS managing director Max Brighton explained that opening APIs to all companies potentially has some technical issues.
“There’s quite a lot of technical work to be done to evaluate what that would look like, particularly in the hosted world where integration with a third party system isn’t as simple as saying ‘you can use our API’,” he said.
A TPP spokeswoman said more than 60 companies are using TPP's free client-side API.
“TPP have already been actively pursuing these data exchanges and we’ve asked for these requirements to become mandatory in the upcoming GPSoC renewal,” she said.
© 2012 EHealth Media.
Mandate open APIs for all health and social care systemsKevin Fogarty ESP IT 72 weeks ago
Why just do GP systems with open APIs whereas we need open APIs for acute, community and social care systems to ensure end to end flow of information to enable continuity of care, improved patient experience and increase patient safety.
This would ensure true inter-operability with ITK and CDA.
eating the elephant: where to startColin Brown 71 weeks ago
Yes: how to make it happen despite the business models of those suppliers who benefit from proprietary lock-in needs tech know-how to specify what data to unlock. This is difficult in the domain of GP systems, which is driven by GPSoC funds.
NHS systems other than for GPs, and social care systems, still have so much data at text or document levels; and how to fund their interoperability looks a huge ask as the above Govt initiative is still at "principles" stage.
Documents are shared also with the world of paper, so who's for interoperability at this level?
Common terminology must be mandated too.Colin Brown 72 weeks ago
Mandating a common API for the many systems now used in shared patient care is a big step towards detail from vague pleading for interoperability. But it's not enough: the data itself needs to be in a computable terminology, or we're reduced to text-only renderings from someone else's system. While some system suppliers still invent their own i.e. proprietary "local" codes instead of using a standard terminology, better access via APIs is a part-solution. This form of proprietary lock-in ("treating customers' data as if it were their own") so cleverly created by some big suppliers, also needs to be locked-out, perhaps also by using their contracts as suppliers to a data-sharing NHS?
Bigger picture?Les Fawcett 72 weeks ago
I hope this does happen, as if done properly it will finally allow integration to start happening in the NHS.
With the demise of a single NHS wide EPR, access to an API (read only will do for a start) will enable portals apps to access patient info currently restricted in propiatry systems. This would mean that the likes of Orion, CareFX, etc. can provide a clinician access to all the info they need about a patient by polling relevant provider systems.
So someone with the correct authorisation (again needs to be done properly) can view both secondary, primary (and possibly social) care records on one screen.
This would blunt some of the work done by InPS and EMIS on their MIG, but would allow CCGs to effectively link all their disparate GP clinical systems togehter and potentially offer the ability to setup and manage links to other their partner providers (OOH, Secondary Care, SE, etc.)
Interestingly this was the model dchampioned by the NHSIA in its last throws before CfH in the ERDIP pilots 10 years ago.
Given the above, my advice to CCG's if this goes ahead would be to start looking at creating their own portal to link partner practices as opposed to being bolted on to the one developed in the local acute Trust.
How would mandatory freely available APIs affect GPs as Data Controllers?Mary Hawking 72 weeks ago
If APIs for anyone asking for them (and not just for trusted partners) become mandatory, how would this affect GP practices as Data Controllers - responsible for the data they control, and the actions of their Data Processors (the GP system suppliers) and their subcontractors - who I would assume would include all the organisations to whom they had supplied the APIs?
Is the suggestion that GP suppliers would have to supply APIs unconditionally to anyone asking for them?
If so, is there any safeguard for the Data Controllers?
or any grounds for claims of negligence against Data Processors (or the Secretary of State for Health) if the access to APIs for all systems is mandated?
API's Don't affect GPs as Data Controllers?Ewan Davis 72 weeks ago
The existence of an API changes nothing, at least at the level of principle, but may have some practical ramifications.
Many uses of the API will be by the patient e.g. A patient using an app to order a repeat script via the API. The app will need to authenticate as the patient just as a patient would logging in direct to patient access. Your duty as data controller remain unchanged i.e. to take reasonably steps to ensure that you person connecting is the patient, or at least someone that the patient has wisely or unwisely, intentionality or not disclosed their login credentials to.
Where the API is being used by someone other the patient your duties are just the same as if the interaction were a manual one or via one of the well established extraction mechanisms, to ensure that the person requesting information or purporting to be acting on behalf of the patient has the right to do so.
Given how easy it is to impersonate a patient or blag confidential data over the telephone from the average general practice (although I'm sure not yours Mary) it seem to me that the sort of authentication mechanism that would be normal for an API provides a much more robust defence.
GP as Data Controllerdavidroyal 72 weeks ago
Mary - I am not sure open APIs would affect our position as the data controller for our patients data. No program should be run using the API without our permission and we should be sure what the program does before allowing this. All an open API would do is move the decision as to what program's and apps we and/or our patients can use out of the hands of system suppliers and into the hand of practices- where of course the decision should be taken.
At the moment system suppliers act as if they own our practice and patient data and are in fact de- facto controllers of who can have access to this data. I would argue that this is breach of the data protection act as well as a commercially questionable practice that skews and distorts the market.
So does the Data Controller have new responsibilities..Mary Hawking 72 weeks ago
.. to ensure that any API access to the system *only* does what it says on the tin - and make sure that the person using the product utilising the API is identifiable and authenticated?
What prevents use of an API to gather lots of data from a system unbeknown to the Data Controller?
And although an App to allow Patient Record Access would obviously relate to one patient, most of the use of APIs is to allow other software (e.g. Docman and Front Desk) access to the whole database: how would I - as a GP and Data Controller - know which developers/suppliers were safe for my patients *without* some form of monitoring by those with greater knowledge such as system suppliers?
Don't forget GPESJohn Pyle 72 weeks ago
The NHS has just committed to spend 6.3 million with the GP system suppliers to develop the capability to deliver data to GPES. Acknowledging that this is not the same as an API, nevertheless I hope that in the process of 'forcing' the suppliers to create open API's we ensure that cost effective ways, building on existing investment, are explored. (GPES Appointment Business case costs at http://www.ic.nhs.uk/webfiles/Services/in%20development/gpes/GPES_Published_ABC__Appendices_v2.0.pdf)
Is GPES Still Locked DownEwan Davis 72 weeks ago
I'm a bit out of touch on the latest with GPES but as I understand it GPES will be a tool for the IC only and anyone wanting to access GP data using GPES will have to route their request through the IC with the service initially only being available to support a limited range of "national requirements"
The contrasts with the old MIQUEST facility that was open to anyone to use subject to getting the GP practices to agree the extract was appropriate and satisfied IG requirements.
It would be good to hear that in the new world of open data and transparency that GPES will be accessible on a similar basis to MIQUEST as while John is right that GPES does not meet all of the requirements of an API an open GPES would meet many of them.
Open APIs, authentication and governanceGuildfoss 73 weeks ago
Having an API is useful - it allows integration with other apps. But having an API with user authentication is essential to address the issues of data ownership. And herein lies the problem of who defines the API and its users ( third party companies, Other clinicians or patients?). To avoid even more vendor lock-in the API would have to be "openly" governed from a technical viewpoint. I do hope that this is a GP community driven initiative and not another top down thing.
Data OwnershipNeelam Dugar 73 weeks ago
Data ownership by the customer has been debated on our PACS forum quite a lot.
1. Does the customer own the hardware on which the data resides. We have seen problems with LSPs PACS contracts where the hardware did not belong to the customers & hence NHS Trusts have had to pay large sums to get data back from Central Data Stores.
2. Does the customer have the tools to migrate the data so that it is in a usable format--should the vendor go bust, end of contract etc and another supplier can ingest the data & display it.
For this to be possible data must be held in standard formats
a. DICOM format for images
b. HL7 CDA/pdf for medical documents
d. Sql compliant Database.
VNA has emerged as a concept in the Radiology world due to problems with migration & data ownership (due to vendors trying to lock-in customers)
Vendors will only support open APIs & open standards when they are required to compete in an open market. NHS needs to be able to change IT systems & getting to grips with good procurement is essential.
Striking a BalanceEwan Davis 73 weeks ago
MrTablet makes some valid points. There are cost to suppliers in delivering and operating suitable APIs which have to be met, but these are vastly outweighed by the value that openness unlocks for the whole system which include significant opportunities for existing vendors with the insight and vision to realign their business models to take advantage.
However, openness is a real threat to those vendors whose business models rely on vendor lock-in and an ability to treat their customers data as if it were their own and they can be expected to raise every possible objection and drag their feet in the ways davidroyal describes above and we should not take too much comfort from their apparent endorsement of open APIs above.
The challenge is how to address suppliers legitimate needs and concerns without allowing these to be exaggerated to support anti-competitive practices.
Current experience is that gaining access to existing APIs can be a difficult, slow process often mired with unreasonable contractual terms and unnecessary NDAs, particular if the requirement is to support a product or service that competes with the incumbent supplier.
Winning the hearts and minds of existing suppliers to new ways of working should be our objective but as Richard Nixon said "If you have them by the short and curlies - their hearts and minds will soon follow!" and the GPSoC Team and NHS CB need to take a firm grip and squeeze hard.
I thought we were learning from historymrtablet 73 weeks ago
"Richard Nixon said 'If you have them by the short and curlies - their hearts and minds will soon follow!' and the GPSoC Team and NHS CB need to take a firm grip and squeeze hard."
I recall Richard Granger striking a similar posture. That ended up as a particular dog's dinner.
Not at all the same and who are you anyway?Ewan Davis 72 weeks ago
I don't think Richard Granger had any interest in the Hearts and Minds of the vendors, other than perhaps as a tasty snack, either for himself or his huskies.
The NPfIT attempted to lock everything down to a few chosen vendors - Many of whom didn't stay the course, and exclude the broader vendor community. APIs are about opening up systems to enable innovation and drive value.
It would be helpful in responding to your comments to know who you (mrtablet) are and where you coming from. It's too easy to hide vested interest behind a pseudonym and while I value comments on this forum from those who for good reason have to stay anonymous, one has to take them with a pinch of salt.
Data Accessdavidroyal 73 weeks ago
Ewan has hit the nail on the head here. "Ability to treat their customers data as if it were their own " goes directly to the heart of the problem.
Ownership of data is a tricky concept but as a GP I would argue that I am the custodian of that part of the record that I make about patient care and would claim full ownership of that part of the record relating to the running of my business and not directly referencing any particular patient.
As custodian of the patient part of the record and owner of the other parts I think it should be me who decides who has access to this data NOT the system suppliers. If I wish to use a particular product that I think will improve the efficiency or safety of my patient care it should be me that decides if I can do this NOT the system supplier.
Data ownership not really a helpful or meaningful conceptEwan Davis 73 weeks ago
You can own a particular copy of patient record but the concept of owning the data in the broadest sense is not very helpful and oversimplifies the situation. Better, I believe, to think in terms of the rights and responsibilities, which might include the right to hold a copy and use it for particular purposes.
I see the patient as "first amongst equals" with regard to their record but HCPs and others have rights that the patient cannot override e.g. the HCPs right to use the record for legal defence or a third parties right not to have their contribution disclosed.
As for the data in a particular system the custodian of that copy is the data controller of the NHS organisation who is contracted to use the system (in this context the GP practice) it is their responsibility to ensure the rights of others are respected.
Suppliers of systems have no rights in the data held in systems they supply and their responsibilities are limited to those things they are contracted to do or the law requires. It's not for suppliers to decide who should have access or if such access meets IG requirements. These and other decisions are for their customer who need to ensure that the contract with the supplier enables them (the customer) to meet their responsibilities to others.
I have more to say on this on my blog