Helping your users co-create the value they need
Who should read this: Government API leaders; CMS-regulated healthcare agencies; Technologists in healthcare; API providers thinking about how to build out their ecosystem; Health and wellbeing app makers; Citizens interested in how they could benefit from giving consent to connect their health records data.

What it's about: In the U.S., the Blue Button API is a technological tool that enables citizens to share their health record data automatically with their chosen healthcare services. This article looks at how we can measure the value that is created by the U.S. Department of Health by investing in and offering this tool.

Why it's important: Public and primary healthcare management requires that a diverse range of partners work together. Citizens need to be able to access their own health data and decide who they share it with. Healthcare services and governments need to make sure a patient's health records are accurate and up to date when making treatment and prevention decisions. Measuring the way the Blue Button API generates value for all stakeholders can help demonstrate that APIs are an effective, efficient, sustainable and secure way to share health data and manage service delivery.

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.

A diagram showing the 5 stakeholders of the digital government data model, the 4 enablers and the three domain areas, as described in the blog post
Platformable's Digital Government 5 wins data model

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
The CMS Blue Button API enables beneficiaries to connect their Medicare claims data to the applications, services, and research programs they trust.

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 At #APIStrat In
We have the API evangelist from one of the most significant APIs out there today at #APIStrat in Nashville next week. Mark Scrimshire (@ekivemark), Blue Button Innovator and Developer Evangelist from NewWave Telecoms and Technologies will be on the main stage next Tuesday, September 25th 2018. Mark …

Interview with Blue Button API Product Manager:

This interview by Skylight Digital discusses some of the thinking behind the Blue Button API.

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.

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 icon

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:

Structured Data Unstructured Data
Number of internal integrations using the Blue Button API Estimation of product development costs from scratch vs reusing Blue Button API in products
Number of integrations using the Blue Button API across all government tiers Estimation of time saved from reusing Blue Button API in government processes
Use case examples and partnership experiences
Citizens icon

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:

Structured Data Unstructured Data
Health outcomes of people sharing healthcare records using Blue Button API vs those who do not Key informant interviews and publications on experiences using Blue Button-powered services and products
Average annual healthcare costs for those accessing Blue Button API-powered services vs those who do not Use case examples and partnership experiences
Usage rates of preventative health and wellbeing apps that are personalised by using the Blue Button API
Health outcomes of those using Blue Button-powered personalised, preventative health and wellbeing apps
Analysis of evaluation studies and online search of research into Blue Button evaluation models
Community icon

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:

Structured Data Unstructured Data
Usage rates of anonymised data Key informant interviews
Number of research projects that have drawn on anonymised data Discussion by academics and government decision-mmakers that explain how Blue Button data is used in planning
Number of successful advocacy and community service planning projects that have used anonymised data
Number of app users who have shared their data with researchers Discussion of impacts on access to data (for example, as discussed in several previous DHHS studies
Business icon

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:

Structured Data Unstructured Data
Number of Blue Button apps User experience of products
Analysis of Blue Button apps and integrations by type of product Business model analysis of Blue Button apps
Usage rates of Blue Button apps
Average pricing of using Blue Button-powered apps and products
API industry icon

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:

Structured Data Unstructured Data
Number of API tools and service providers with health sector clients Onboarding and sales funnel experiences of API industry when working with healthcare sector
Contribution of healthcare sector to API open source related projects Identified feature enhancements of API industry built to meet healthcare sector specific needs

Regulations icon

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:

Structured Data Unstructured Data
Description of relevant regulations Key informant interviews
Breaches and complaints made under regulations

Citizens icon

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:

Structured Data Unstructured Data
Monthly average unique visits (new vs returning) to the Blue Button API developer portal Key informant interviews and experiences using the Blue Button API developer portal
Analysis and categorisation of available Blue Button developer resources Sentiment analysis and discussion analysis of Blue Button hashtag and Forum engagement
Engagement with Blue Button developer resources

Standards icon

Standards

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

Secondary questions:
  • How are stakeholders engaged and encouraged to use relevant standards?
  • Whata 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:

Structured Data Unstructured Data
Analysis of standards used in Blue Button API and in apps created Key informant interviews
Timeline on standards key milestones International comparisons on ecosystem growth and viability in jursidictions where standards are not required
Organisational map of how standards are agreed, adhered to, and implemented by stakeholders Analysis of governance decisions that involve standards

Security icon

Security

Key question:
What are the security risks and ouctomes 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:

Structured Data Unstructured Data
Analysis of security breaches catageorised by OWASP criteria Key informant interviews and publications on healthcare technology security risks
Analysis of adoption and planned adoption of security technologies in apps using Blue Button API Discussion of whether security is made a first order concern and embedded in API review and app development processes

Equity icon

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:

Structured Data Unstructured Data
Usage rates of apps disaggregated by race/ethnicity, age, gender, zip code, income, housing type, language spoken at home, disability, and comorbidities Key informant interviews on access and ease of use of apps amongst marginalised populations
Number of apps that meet accessibility guidelines Experience of startup and small business app makers and acces sto markets
Number of apps that have a target focus on marginalised populations and those that support people with specific healthcare needs Average costs and rebates available to small businesses building Blue Button-powered apps vs larger enterprises
Access to digital resources (internet/wifi, technology and skills) amongst marginalised populations

Engagement icon

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:

Structured Data Unstructured Data
Number of decision-making bodies that include patient and citizen representation Key informant interviews and publications on experiences when engaging with digital healthcare products
Roadmap of use cases and needs to be addressed in future iterations of Blue Button API Discussion of how use cases are identified and prioritised
Engagement icon

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 appps 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:

Structured Data Unstructured Data
Analysis of average energy and waste costs generated for an app powered by the Blue Button API vs other forms of healthcare delivery Key informant interviews and publications on technology sustainability
Number of apps that include suggested preventative health behaviors such as giving up smoking, walking and cycling Discussion amongst app users on uptake of healthy behaviors and estimates on reductions in unsustainable impacts

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:
Screenshot of landing page of Data at the Point of Care pilot API
Data at the Point of Care pilot API landing page

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

If you are a government agency that would like to work together on mapping the ecosystem value of your APIs, contact mark@platformable.com or book an appointment with me directly:

Acknowledgements

I'd like to thank Kin Lane for inspiring me to map Platformable's Digital Government 5 Wins Data Model against the Blue Button API ecosystem and for guidance on continuing with this project.

This post was last updated on 7 May, 2020.