I have a simple request: no public money should be used to buy software to store patient data unless the software provides an open API for other software to access the data.

AT&T opened up its telephone interface - letting its optical fibre network communicate with other telephone companies - building a continental telephone system at the start of the 20th Century. Other countries opened up their telephone interfaces to allow international telephone calls.

At the end of the 20th century, the UK led the way by opened its telephone interface to internet traffic. The result was Freeserve, which brought cheap internet connectivity to the UK and was quickly adopted across Europe. The UK also led by opening its mobile phone networks to new entrants, adopting the GSM global standard, and rolling out phone number portability.

This allowed for some of the cheapest and highest mobile adoption in the world. UK tax revenues of £22.5 billion came from the 2000 3G auction. This early adoption helped create Vodafone, the world’s largest mobile phone company.

It is worth spelling out that the openness of these interfaces made a market with freedom to operate, not a market of free prices. Connections between telephone networks cost money and we expect the same for medical record APIs. It is the ability to operate in a competitive market that generates widespread technology adoption.

Cheap and widespread communication technology transformed every aspect of society, including healthcare. The next wave of transformations will be from the digitisation of records. This is why the UK government has funded healthcare IT in the past, with paperless GP surgeries before most of the OECD countries. And this is why the UK is expanding its funding for this process, pledging paperless hospital records by 2020.

Open application programming interfaces (APIs) are key to making sure the impact is widespread.

What is an open API?

A few words on what the technical terms mean. In computing, an interface lets a computer communicate with another party. A programming interface means the computer receives and responds to an instruction. An 'application programming interface' means the party issuing the instruction is a software application. This is different to a user interface that lets a user communicate with the computer; a graphical user interface (GUI) has human-friendly graphics for the communication, e.g. windows, icons and touching.

An API lets computers work together without the need for human beings. It generates massive efficiencies through automation. It also enables work that humans find impossible, such as searching through billions of records in seconds.

Note that storing your medical records in software with an open API does not mean that anyone can access them. To use the API on real data requires permission from the administrator of the software and data: your GP, your hospital, or you the patient, as the case may be.

If the data administrator does not give permission to a software developer, the developer cannot open your record. Opening up the API is separate from opening up the record, and rightly so.

The role of the open API is simply to greatly reduce the costs and time for developers to learn how to use the API. This in turn increases the quality and supply of good developers that administrators can choose to work with, which means you get the best innovation for improving your health.

What makes a good API?

A good API will have several properties: its data should be machine-readable; the details of the API should be openly published, open for testing, and without copyright restrictions; it should have global usage; it should allow data to flow in two directions; and it needs all of these properties enforced for compliance.

To illustrate how this works in practice, I am going to explain how this would work for the GP open API initiative. The same lessons apply to any open API for medical data.

Machine-readable

Every data point should have a code that computers can understand. This means computers can then display the data in relevant ways like plotting charts of related blood tests. They can analyse the data, and identify which patients’ blood tests show a risk of hospital admission. The system can then support decision-making by suggesting changes in medications that would prevent the admissions.

There are international standards for machine readable medical records: SNOMED CT, ICD9 & 10. The Government have pledged to move to records in SNOMED by 2016.

Early versions of GP medical information software produced records that were in principle machine readable. But this did not include data that was enhanced by recognised national or international standards. This meant data under e.g. a diabetes diagnosis could be displayed on a table, but it wasn't always clear what the values represented: were they blood glucose levels or something else?  

Openly published

The full specification for the interface must be available with no need to fill out forms. Access to see the API does not mean access to the data; it is right and proper that the latter requires vetting and regulation. Developers need to see the API to experiment and learn with others before they build something useful enough to attract investment.

The software companies that have been approved as GP Systems of Choice, and NHS England, are forcing developers to justify their access before they can see the API. Often the answers to the questions are not available until a developer understands the API.

Open for testing

We need an NHS England-funded Sandbox that lets any developer access test data within 5 minutes. The team creating the sandbox should have their funding determined by how many API calls are made to the sandbox.

This is how companies outside healthcare pursue maximum adoption and thus maximum innovation: Twitter, Facebook, Google, Microsoft and numerous others all understand the importance of the quick start.

Open copyright for the API specification

All other developers must be able to match the same API specification for interoperability without fear of copyright lawsuits. The US Supreme Court case of Google vs Oracle is about this very issue, with civil society supporting Google’s case that APIs should not be copyrighted.

The policy sidesteps this legal argument allowing funding to APIs which have been voluntarily openly licensed without copyright restrictions. They exist, we simply have to choose to use them.

Global

Only if international standards are chosen will UK citizens and UK providers get to choose the best software from all over the world rather than the local providers NHS England’s past policies have left us with. We recommend HL7 v3 FHIR, but others exist.

UK software companies in turn can sell their UK-developed software in the international market rather than being locked into the small local one. This is how Freeserve, Vodafone, O2, Lycamobile and others are created as national champions with global leadership.

Two-way

Data from external sources, including patients, should be able to be stored in the NHS data set. At the moment, GPs can only receive data from patients using software made by the GP System of Choice companies, or parties approved of by those companies. The decision over approving the source of the data should reside with the GP or NHS England not the software company.

Enforced

There should be public testing for every data point to ensure the data are semantically usable by other software providers. This is the role of the regulator: not to build or buy the software, but to make sure that what is bought is built to the policy of open APIs.

Being Square matters

To see openness in action, consider the story of Square, which makes a square-shaped device that transforms a smartphone’s headphone socket into a credit card reader. Its founder, Jack Dorsey, was previously co-founder of Twitter. In 2009, he discovered that the headphone socket of his iPhone could be used to transmit more than just audio. He did not need permission to discover this or to experiment with the headphone socket, he was simply able to start building his prototype for a use never imagined by any manufacturer.

Square allows anyone with a smartphone – a taxi driver, a nail salon owner, a cub scout – to process credit card payments. This year it will have processed $30 billion of transactions.

This is the innovation that comes from openness. This is what we need in healthcare.