Over the last decade, governments around the globe have been shifting toward open API infrastructure. When done correctly, this open ecosystem should enable them to partner with third parties to reach more citizens and businesses digitally, to automate and optimize processes, and to leverage emerging technology like smart city sensors and the Internet of Things.
The problem is, if it’s not done well, an API program risks increasing inequality among constituencies, especially those most vulnerable.
We spoke to Mark Boyd, director of Platformable, a consultancy specializing in open ecosystems and the data driving them. He looks to create a different open ecosystem that changes the way we do business in order to actually improve citizen lives.
The Case for an Open API Ecosystem
Even before the current pandemic, Boyd witnessed a lot of move toward open APIs and microservices at all levels of government, as rapid population growth demands that civil services move faster via more composable product development.
“As the population increases, especially in urban environments, the governments aren’t going to be able to keep up with all those citizen needs. There’s a need for APIs for third-party developers to address those needs,” Boyd said.
He cited many projects including diabetes research shared via an API by the Australian state of Victoria. Their internal health department provides websites with broader research, but by releasing their research via an API, external organizations are able to focus on serving subpopulations, including Aboriginal and Torres Strait Islanders (ATSI) Australians.
“It’s not to say that governments don’t have a responsibility to provide that, but, by enlisting third-party developers and specialists, they can serve the underserved faster.” Boyd commented that normally this demographic drill-down information is trapped in an archive somewhere because the government doesn’t have enough resources to fund it. Unfortunately, that means this high-risk indigenous population goes under-served. Yet again.
The potential for government open APIs to leverage third-party integrations to innovate is endless but that doesn’t mean it’s widely enabled yet. Boyd shared the example of the European Centre for Disease Prevention and Control (ECDC) which collects a wealth of data around the ongoing COVID-19 pandemic, but only shares limited information weekly. It allows for analysis by age and gender, but does not share for race, migrant or socioeconomic status.
Notably, due to a massive healthcare talent gap, there are a lot of Filipino nurses who live and work in European countries, but there’s a lack of data on their COVID outcomes. “Migrant workforces are invisibilized,” Boyd said because this subpopulation’s anonymized data isn’t being shared for analysis. Only Finland has an open API for COVID data.
Before mapping open ecosystems, Boyd worked in Melbourne setting up patient representative organizations with people with HIV during the AIDS crisis. Then he became a health inequalities officer, “working at the local government level of how city governments can improve population health and wellbeing at the data level.” That’s when he started to see the potential of open API ecosystems.
Equitable API Design
As we already know through the varying disasters that have been COVID-19 contact tracing apps, the socio-technical impact on citizens is not often factored into government strategies. Dr. Virginia Dignum describes socio-technical responsibility as a mix of:
- Health
- Safety
- Non-discrimination
- Accessibility
- Inclusion
- Freedom of association
These considerations are not just applied one-off but are continuously measured and revisited. Sadly governance is one of the weakest links in any API program.
“In health, if you want an open ecosystem, you need to get your data governance right.” Boyd continued that “The issue along the way with health inequalities is that people don’t factor that into how they design things.”
This negligent omission becomes amplified with open API programs because the whole point is to “turbo-charge everything — technology on steroids,” as Boyd called it, with everything faster at scale. This means you get inequalities at scale, further disadvantaging part of the population by causing less reversible harm.
We’ve seen this as of late in facial recognition, which to start doesn’t usually have enough samples from darker skin tones or women to be accurate at identifying anyone but white men, which is why it often increases racial profiling and inaccurate crime accusations. Artificial intelligence, in general, is already being used to deny people healthcare in the U.S., to push people out of employment opportunities and to discriminate against people for loans.
As Boyd reminded us, “API-enabled architecture is what makes the artificial intelligence and facial recognition possible, but at the time it was being introduced, API architects were saying ‘That’s not our issue — they should be looking at it’ [pointing to AI teams.] And then AI said it was the API people’s responsibility.”
He calls APIs the tail wagging the dog that hopefully forces these kinds of discussions.
AI ethics now is a more common — though not nearly common enough — practice, but consequences are still not being considered at the API architecture level. Of course, the best system would perform consequence scans at both AI and API levels, which would make it more efficient for both teams.
When deciding when to build an API, Boyd says you should be thinking about:
- Who is it for?
- Who will benefit from this?
- Can everyone benefit from this?
For example, yes everyone would benefit from knowing COVID-19 health risks for an overall area, but even more so from anonymized but still granular local data. It may change citizen behavior in an outbreak area. But it could also shed light on certain likelihoods like how people who live in low-income areas tend to have a higher risk as they tend to live in smaller more condensed homes with worse or no ventilation systems. Organizations serving this community can’t currently reap those benefits because no one is exposing that data via an open API.
After finding out that many constituents weren’t even aware they were entitled to some health services, New York city’s NYC Screening Benefits API was released to government, community, health insurance, and other services to integrate the API into their client intake processes. Now, New Yorkers can plug in their demographics in order to check their eligibility for a range of city, state and national government services.
“The design of the service enables people to anonymously check their eligibility so that the service is available to undocumented New Yorkers who are not accessing the services they can due to fears of data insecurity.” Boyd said this API was designed based on feedback from the at-risk community.
Inequitable by Neglect
Of course, careful considerations can open up to more abuse as well. For example in Madrid, low-income, heavily refugee neighborhoods had restriction of movement while other more affluent areas had none. It should be used to solve problems of lower vaccine rates or inadequate housing among a community, but instead, it’s being used to create more separation and inequity.
“The issue with APIs is they aren’t just a technology. APIs are a business contract, embedding the policy within the API. Inherent in an API is a policy world view from the government.”
— Mark Boyd, Platformable
Deciding which APIs to expose to third parties will always have that policy lens, but working with external partners opens up the ability to serve different communities in different ways, putting much of the decision-making into those external experts.
Government will never be a purely technical concern — it’s not just about building an API. You need the policy people and the communities represented by this data in the room, making decisions about the data together with technical stakeholders. It’s the only way to increase innovation at scale, while serving groups at a granular level.
Boyd gave the example of the U.K.’s NHS which opened all the electronic healthcare records at an anonymized individual level. “There are actual benefits for society, but you can’t just do a whole scale of population at once. You’ve got to work with each patient represented group to understand the value of the data.”
Addressing equity in APIs is also about new approaches to tech policy. There’s a noticeable increase in using regulatory instruments for managing big tech, open banking, and health data,
but Boyd pointed out that government still has this bad habit of holding a policy meeting, releasing results and then only revisiting three years later. But with faster release and development, governments have to have much more regular citizen engagement.
He also shared the example of Open-311, a North American city app that works as a communication channel concerning public spaces and services. For example, someone could report that a bus stop has been vandalized, which pings asset management and assigns someone to maintenance. The citizen gets a text back — thanks for letting us know, it’s been fixed — and then the data is released anonymized in real-time. But in creating the API design, it is not considered how this will impact on specific populations or neighborhoods. Residents of lower-income neighborhoods work longer, more demanding jobs, may not have unlimited mobile data, and traditionally have a reasonable distrust of government. This all combines to mean they are less likely to report to the app.
Unless you factor that community perspective in, the Open-311 system will send all resources to the higher-income neighborhoods. Which structurally embeds the inequality. Instead, Boyd offers ways to design more equity in an inequitable system:
- Make sure the postal code is an essential part of recording.
- Put sensors on fleet vehicles to map potholes and make sure route teams go into lower-income neighborhoods more to automatically trigger requests to maintenance, so residents don’t have to report.
- Plan out how you will educate under-served neighborhoods about Open-311.
Around the world, they’ve put city bike schemes in higher-income neighborhoods first, while lower-income are more affected by pollution and are likely to live farther from work. In New York City, the collection of data around the bike scheme is all shared through an open API which is driving decision making. Except that they are basing decisions on the level of city bike usage in predominantly high-income neighborhoods. And then a supermarket decides based on these datasets, so then lower-income neighborhoods have persistent food insecurity, and a small API ends up supporting inequity at scale.
Similarly, we now know that oximeters, which measure the all-important oxygen level of COVID-19 patients, perform inaccurate reads on darker skin tones. These are sensors connected via APIs — did no one consider ahead how it would’ve worked on different patient demographics?
API architects must become the necessary bottleneck, asking: Where are we getting this data from?
“Let’s open that API, but no one’s thinking about does that API reinforce that structural disadvantage?”
— Mark Boyd, Platformable
The Power of API-First Design
“If the API is expected to have benefits for the whole society, delivering greater value, then you need to go through some sort of impact assessment phase, get the policy people in the room, and talk through the potential impacts that can be entrenching existing inequity.” Boyd calls API design a team sport that needs to bring business, policy and architecture together over people-centric design.
Boyd is the lead author for the API Framework for Digital Government for the European Commission, which looks to apply a more cohesive approach to app modernization, instead of just making things more complicated. It follows 12 proposals:
- Align APIs with policy goals.
- Define the government open API platform vision.
- Create API governance structures.
- Form guiding principles for API processes.
- Design metrics and prioritize APIs by policy areas.
- Harmonize data models and other platform and ecosystem assets.
- Establish cross-organizational teams.
- Follow an API product approach.
- Measure policy impacts of APIs.
- Build API platform components.
- Appoint API product managers.
- Adopt an API lifecycle approach.
Most importantly, don’t assume that another point in the chain is going to reflect on any technology’s consequences. At each stage of the chain, everyone must consider ethical and responsible tech ramifications.
Boyd said that a lot of this can even be embedded in policy as code, which demands more actions at scale. For example, if an API is predicted to reach a million calls, you need the requirement for an impact assessment document embedded into your DevOps pipeline.
Feature Photo by Marco Oriolesi on Unsplash.
