We need governments to adopt APIs across the board as part of their digital government efforts. APIs (application programming interfaces) are a way to connect different systems together. They are more than just a technical IT solution, though, because using APIs would help ensure that:

• Data can be shared
• Systems are interoperable across borders
• Governments can build new services and products faster and more sustainably by reusing components
• Governments can work in partnership with community groups, nonprofits, industry and research
• Data can be fed into machine learning systems to gain insights and automate large data processes (for everything from sending out stimulus support cheques quickly to optimising replenishment of city rental bike docks).

Governments are increasingly adopting APIs but it is being done in piecemeal fashion, and even now with the impacts of COVID-19, governments aren’t really looking at how to introduce API infrastructure to share data or examine supply chains. But digital government APIs in the time of COVID-19 are more important than ever.

Who should benefit from digital government APIs?

Platformable’s 5 wins model has identified 5 key stakeholders who should benefit from government API action, as well as 4 enablers that will foster the right environment, and 3 domain areas that government must address.

Government APIs should support the following stakeholders:

• Governments themselves: APIs should help governments be more efficient, build solutions faster, and reduce duplication.
• Citizens: APIs should help citizens interact more easily with government (when and where they want) and more seamlessly (having to repeat themselves less often), with less waiting times and less paperwork. Trust should be increased because citizens see a clear feedback loop, are confident that their engagement is valued, and because decision-making (including spending) is more transparent.
• Community and research: Community groups should be able to provide services and support their constituents with greater information access and less bureaucracy. Researchers should be able to collaborate and share their results with policy-makers more easily.
• Business: Businesses should be able to reduce paperwork, meet regulations responsibly, pay taxes automatically, and be supported to become local economic powerhouses. Industries should be able to work together in standardised ways where possible and compete on a level-playing field.
• The API industry: Because governments are big organisations, their use of APIs will help speed up industry knowledge and maturity so that everyone can benefit from seeing how governments implement new technological solutions.

In the digital government API context, there are 4 enablers that will help generate these above benefits:

• Regulation: Regulation can help facilitate appropriate use of APIs and reduce the risk of negative detrimental impacts, such as privacy exposures or industry monopolisation.
• Developer Experience: Making APIs easily understood by internal and external stakeholder developers will be essential to ensure the efficiency and other benefits of government APIs are realised.
• Standards: API standards, standard data models, and data glossaries can all help ecosystems to work collaboratively and speed up development. This will also help new businesses scale their products and services to other geographies and markets.
• Security: Best practices in API security and data privacy will need to be implemented in a government API framework to give all stakeholders confidence and to reduce the risk of threats.

But governments also have other, specific roles and a general purpose that means that we can’t just look at private industry and see how they are adopting APIs and replicate that in government circles. Modern, democratic governments also have responsibilities to address across three key domains:

• Engagement: APIs in government settings should enable engagement by all stakeholders.
• Sustainability: APIs in government settings should facilitate sustainable practices where resources are used within limits and infrastructure does not provoke high energy consumption or create costly builds.
• Equity: Government API activities must conduct impact assessments and measure differential outcomes by key sub-populations, business size and location to ensure that this technology does not inadvertently widen systemic inequalities.

How to use this model

Platformable uses this model to identify key trends in government APIs. Like our open banking work, we will be producing quarterly trends reports and annual state of the market reports to dig into what is happening with government APIs and analyse how they are generating value for everyone. This work (along with our consultancies, such as our recent work developing an API Framework for the European Commission) is helping us identify additional government needs. Already, we have identified a few specific products to work on to support governments introduce and manage APIs:

• A best practice monitor that highlights and shares government API best practices around the globe
• An online assessment tool and action planner to measure the maturity of a government API strategy
• An API framework training tool based off the work to be published by the European Commission
• A government API equity oversight and impact assessment tool
• A suite of tools to help governments better measure the value of their APIs.

If a government has implemented APIs in a given area, they can use the Digital Government 5 Wins Data Model to assess how well they are cultivating an ecosystem around their APIs. This data model helps them quantify the value their APIs are generating.

Industry, community groups, researchers and the API industry can use the 5 wins model to help assess a government’s API program. The model should help any stakeholder determine how much work will be involved in partnering with government and give some indications of whether the effort will be worth it.

The Blue Button API

One example of where an API strategy has been adopted is the United States’ Blue Button initiative. The Blue Button API is a digital integration tool that helps citizens to share their health data with their healthcare professionals and providers.

The U.S. Department of Health and Human Services (DHHS) maintains a database that securely holds the U.S. Medicare and Medicaid electronic health records of over 53 million Americans. This database (no doubt growing as more Americans need Medicare and Medicaid coverage) includes data on their health, including the type of Medicare coverage they have, drug prescriptions information, primary care treatments, and costs. The Blue Button API can be used in apps to connect to this database. When a citizen gives their consent, the app can access their healthcare data via the Blue Button API. This might be done so the citizen can quickly share their healthcare data with their healthcare team, or to monitor their health and wellbeing themselves.

Data stored in the Blue Button API can also be aggregated and anonymised for use by researchers. In an app, patients may give approval (consent) that their anonymised data is shared with a research team working on improving health outcomes.

The diagram below gives a simple overview of how the Blue Button API connects to the Medicare database and enables apps to be built that create real value for citizens, the community, research and business.

Before we look at how to apply the Digital Government 5 wins model to the Blue Button API, it is worth exploring a few of the drivers of government APIs and what the Blue Button API says about how governments will operate in a digital era.

Why are government APIs like Blue Button so important?

Governments are changing. Citizens and businesses are demanding that government be accessible via digital means. We want to be able to visit a website and find out information without having to go into an office or make a phone call. We want to be able to lodge our tax returns online at any time of the day or night. We want to complain about a street pothole, apply for rebates, provide feedback on neighborhood plans, see what events are coming up in our community, check our eligibility for support services, record our business’ operational health and safety data… and so on. This means government must create digital services for all of these things. This might involve creating a webpage, but also an app for Android, an app for iPhone, maybe they want to experiment with creating chatbots that can respond to all of these types of requests (that’s another service to create), and then they also have to make sure they still run physical services for those without internet or mobile capabilities. So that is a lot of additional work and resources if they don’t build them in a way that the same APIs created for the online site can be used for the mobile apps and the chatbots, but even then it’s still a lot of work. So choices need to be made about what are the priorities.

Solutions require ecosystem approaches. As COVID-19 and the climate crisis demonstrate, today’s most challenging problems cannot be solved by government alone. In just the one area of COVID-19 testing, we have seen the need to involve:

• Multiple government departments in the one government
• Multiple layers of government…
• ...Across multiple government borders (city, county, state and national)
• Supply chain industries
• Researchers
• Laboratories
• Logistics providers
• Community groups and advocates for the disadvantaged
• Medical and health care providers.

Governments need to create the means to enable all of those stakeholders to work together. That generally means being the agency that brings everyone to the table (an ecosystem facilitation role), but they can also encourage (or mandate) that certain standards be used so everyone is using the same models to build with. They also usually take a communications role in updating everyone within the stakeholder network on what each of the other partners is doing. With private industry and research partners, they have to negotiate what can be shared openly, and what represents commercial-in-confidence.

Government as wholesaler. Given the resource constraints and the need for ecosystem approaches, governments need to make decisions on what is central to their role, and what should be done by ecosystem partners. For example, government health departments have a responsibility in providing diabetes healthcare information resources. They often fund new research and have a responsibility to convey that research to their citizens. But how much should governments build themselves, and could they produce more if they involved healthcare startups and external researchers? If they opened diabetes information via API, could they fund external parties to create apps and services for most impacted population groups so that the diabetes information got to those who needed it? If it was available via API, it could also be integrated into other existing apps and services used by people with diabetes (such as nutritional apps or grocery shopping apps, for example). So they could reach a lot more people at the times they need the information, rather than expecting everyone to come to the government’s website and navigate from the main site, to the health department site, to the preventative health area of that site, to the diabetes subpage and then to the latest info resources on that subpage.

Prioritising interoperability. The European Union and the United States both have concerted efforts to enable greater interoperability across borders. The European Union is made up of 27 member states, and citizens should be able to move freely within the Union and access healthcare from anywhere, as needed. They should be able to do so by sharing their health data so that the healthcare professional who sees them on holiday can understand their current medication regime and prescribe without causing contraindications. In the United States there are 50 states, and healthcare should be seamless if someone moves from one state to the next (or even from one county to another).

APIs like Blue Button are addressing all of these drivers and creating a new type of government service. But because this is a whole new paradigm for government, we need to be diligent about watching:

• Is this an efficient and effective way of working?
• Is it reaching those who need it?
• Is it creating new local economic opportunities?
• Is it inadvertently creating new imbalances of power?
• Is it inadvertently blocking access to those who have already previously been systemically disadvantaged?

Evolution of the Blue Button API

Official Site: Blue Button 2.0

Industry view of the API:

Kin Lane, an API industry leader and former Presidential Fellow, describes the Blue Button API as “one of the most significant APIs out there right now” because of API reach, use of standards, and because it provides “a potential blueprint that other federal and state level agencies can follow”.

API Evangelist | Talking Healthcare APIs With The CMS Blue Button API Team 

Department-of-veterans-affairs/VA-Micropurchase-Repo

Public site for VA API Platform Micropurchases. Contribute to department-of-veterans-affairs/VA-Micropurchase-Repo development by creating an account on GitHub.

GitHubdepartment-of-veterans-affairs

Applying the Digital Government 5 Wins Data Model to the Blue Button API

2,000 words into this article, we get to what this is all about. This is not uncommon when discussing government APIs. The reason for this is that APIs are a fairly new approach that, as demonstrated above, are reflective of a paradigm shift in how government operates. So quite often, we need to discuss the why in detail first. In my case, I also had to explain the Digital Government 5 Wins Data Model we have developed at Platformable.

So to sum up what we have discussed so far, here is the view of how access to the Blue Button API creates new apps and products and how this flows on to generating value for various stakeholders:

Thanks for bearing with me. The rest of this article now looks at how to apply the model to the Blue Button API. A follow-up article will then actually share the results of this data collection. This article is about proving the case for measuring a government API’s ecosystem and describes how to do it. Phew! 😅

Key indicators in the 5 wins data model (as applied to Blue Button API)

Governments

Key question:
Does the Blue Button API help the DHHS be more efficient, build solutions faster, and reduce duplication?

Secondary questions: 

• Can the DHHS calculate how much is saved in one year by making the Blue Button API available?
• Is the Blue Button API reducing costs at all levels of government?
• What type of efficiencies are being generated through the Blue Button API (reduced duplication, faster product development, cheaper onboarding and management of partners, etc)?

Data sources to answer these questions:

Citizens

Key question:
Do citizen health outcomes improve with access to digital products built using the Blue Button API?

Secondary questions:
 

• Are stress and confusion reduced for citizens who share their data across multiple healthcare professionals using the Blue Button API?
• Are citizens able to get faster, higher quality healthcare at lower cost due to using digital services connected with the Blue Button API?
• Are citizens able to take proactive, preventative health measures by using digital apps that use the Blue Button API?

Data sources to answer these questions:

Community and Research

Key question:
Are community organisations and research institutions more effective because they can access aggregated, anonymised data on health incidence and outcomes by using Blue Button API data?

Secondary questions: 

• Does aggregated, anonymised Blue Button data better inform service planning and reduce costs of healthcare?
• Do apps powered by the Blue Button API increase access to data for use in research?

Data sources to answer these questions:

Business

Key question:
Have new health startups been able to create viable products and services for citizens by building with the Blue Button API?

Secondary questions:

• What types of products are startups and other Blue Button integrators building?
• Does use of the Blue Button API reduce business operational costs?
• What new revenue and transaction volume is being generated by using the Blue Button API?

Data sources to answer these questions:

API industry

Key question:
Are API tools and service providers able to mature by working with DHHS and healthcare organisations?

Secondary questions:

• Are DHHS and related government health agencies contributing knowledge to the API sector?
• Are DHHS and related government agencies buyers of API tools and services?
• Are the uinqiue needs of the healthcare sector helping advance the maturity of the API sector?

Data sources to answer these questions:

Regulations

Key question:
How does mandated use of the Blue Button API by Medicaid-funded providers support industry growth and citizen data privacy?

Secondary questions:

• What regulations are in place for the Blue Button API?
• How are regulations creating a safe sectoral environment?

Data sources to answer these questions:

DX experience

Key question:
Is the Blue Button API easy to use and integrate?

Secondary questions:

• How long does it take a new business to test and integrate with the Blue Button API?
• What developer resources are most used?
• What is the rate of churn amongst those businesses who initially wanted to use the Blue Button API but did not build products?

Data sources to answer these questions:

Standards

Key question:
What standards does the Blue Button API utilise?

Secondary questions: 

• How are stakeholders engaged and encouraged to use relevant standards?
• What are the governance processes to define and ensure adherence to standards?
• How do standards impact positively and negatively on ecosystem stakeholders?

Data sources to answer these questions:

Security

Key question:
What are the security risks and outcomes from the Blue Button API implementation?

Secondary questions:

• What are the greatest security risks and how are they managed?
• What security breaches have occurred?
• How often are security risks reviewed and updated?

Data sources to answer these questions:

Equity

Key question:
Are the benefits and advantages of using the Blue Button API shared by everyone?

Secondary questions: 

• Is data on usage and outcomes of apps powered by the Blue Button API able to be disaggregated by gender, race, age, income level, and zip code?
• Are startups and SMEs disadvantaged against larger enterpises in building products with the Blue Button API?
• Do apps and products built with the Blue Button API reduce health inequities outcomes?

Data sources to answer these questions:

Engagement

Key question:
Do citizens and stakeholders participate in decisions on how to manage the Blue Button API?

Secondary questions: 

• Do governance and planning processes involve citizens and other healthcare stakeholders?
• How does DHHS and the Blue Button API team identify new use cases and user needs?

Data sources to answer these questions:

Sustainability

Key question:
Are Blue Button API operational costs encouraging greater sustainability through efficiency, reduction of waste and resource use, and by facilitating sector-wide sustainable healthcare practices?

Secondary questions: 

• Do apps and products powered with the Blue Button API reduce waste and energy consumption?
• Are preventative apps and products built using the Blue Button API facilitating sustainable behaviours?

Data sources to answer these questions:

Next steps

This article has aimed to give a solid overview of how you would build a data system that measures the ecosystem value generated because the U.S. government released the Blue Button API.

There is now more work to do! This article represents the start of a project we are undertaking at Platformable. The next stages for this project are:

• Measure the ecosystem using the metrics identified above 👆🏻
• Work with the API Evangelist, Kin Lane, as he builds his thinking on this as well. He has started by documenting the building blocks that make up the Blue Button API.  His model measures the API lifecycle and product management components, which come up in the 5 wins model partly under "Developer experience" as an enabler, but he goes deeper into how an API provider makes sure their APIs work effectively using best practices. Kin is also encouraging me to think about which of the 5 wins data sets could themselves be APIs that can be used to automate reports monitoring the ecosystem value being generated. He also takes a "total addressable market" approach to the Blue Button API, which I hadn't really thought through before. The 5 wins model starts from the existing ecosystem being built around a government API. Kin steps back and asks "How many potential stakeholders are there that could be building with the Blue Button API (and why aren't they?)"
• Compare the Blue Button API with a best practice government API example. Identify a best practice government API and track two startup applications: one that uses Blue Button API and one that uses the best practice government API to compare where roadblocks, obstacles, bottlenecks and challenges are experienced, and where developers are supported through the development process to build products and services quickly and seamlessly
• Identify the various roles and stakeholders at Federal, State, County, and city level to understand how the Blue Button API works across government tiers and to understand the impacts this government structure has on API ecosystem growth
• Compare with similar, global government health APIs and build a network committed to best practice
• It would be useful to share the learnings of the ecosystem value being generated with the Blue Button API with the team that is now building the pilot Data at the Point of Care API:
•  

If you would like to keep updated about this project and Platformable's other work on Open Health APIs, subscribe to our newsletter: