Digitizing public services can help governments reduce administrative burden, develop new functions, and provide citizens with streamlined processes that span sectors. This is e-government: where information technology helps provide public services to citizens and businesses while also increasing efficiency and transparency. From a citizen’s perspective, it means no more filling out paper forms or visiting government offices; instead, information is exchanged automatically between agencies.
E-government is an interoperability puzzle whose main pieces are APIs. Creating a single, streamlined online process whose underlying complexity is hidden from the user requires seamless communication between the government agencies and systems involved. But APIs aren’t the only actors at work. Interoperability on a broader scale requires common standards, guidelines, and practices, as well as collaboration within administrative sectors, across borders, and between the public and private sectors. As CTO of the Nordic Institute for Interoperability Solutions (NIIS), I see these issues in my work in Nordic and EU countries.
The once-only principle
The once-only principle (TOOP) is an e-government concept developed by the European Union. Its goal is for citizens, organizations, and companies to have to provide certain information, such as an address, to authorities only once. The information is then stored in a single repository and shared between authorities that have a right to access it. In practice, this means that if one agency has already collected and stored a piece of information about a citizen, another agency needs only query the authority that “owns” the information in order to access it, instead of going back to the citizen. Population registries, like those maintained by Finland and Estonia, are a common source of data for other government agencies and businesses since they contain information such as names and addresses.
The idea behind TOOP is simple, but implementing it is not. It requires base registries (which the European Commission defines as “a trusted and authentic source of information under the control of a public administration or organization appointed by government”), along with all related information systems and services, to be accessible and interoperable. APIs are central to implementing TOOP, as they enable data exchange between authorities. But successful implementation also requires secure data exchange solutions, unified data models, and semantic interoperability across different information systems and applications.
But how can authorities be guaranteed access to the data they require without compromising individual privacy—and without implementing a burdensome administrative process? Differing processes can add complexity: Typically, each authority defines the administrative process by which another organization can access its data. For an organization that needs data from several authorities, that means having to go through multiple different processes.
Cross-border data exchange
Technically, data exchange across borders should work the same way as data exchange within a country—APIs, after all, enable data exchange without regard to geography. In practice, however, APIs are more likely to differ between countries than within them. Commonly used API guidelines and best practices are not official standards, which leads to differences in their implementation. For example, HTTP headers with a custom “X-” prefix may be used instead of standard headers sometimes. Things like this don’t prevent the data exchange, but it does mean the exchange requires more effort. Sometimes, cross-border data exchange requires changes to an API. A common solution is to implement an external adapter service component rather than creating a new version of the API. Business data may have to be wrapped inside an additional message envelope, which is often implemented using an added adapter component.
Several European countries already have national API strategies, many of which include guidelines for API creation. However, guidelines (and their level of detail) vary between countries, as do national adoption rates. In other words, having national API guidelines doesnʼt mean every agency has fully adopted them. Still, cross-border data exchange is already happening between some EU member states, and solutions have cropped up to make that exchange easier. Some target cross-border data exchange for specific business domains, such as Peppol for e-procurement systems and eHDSI for health data exchange. Others target both national and cross-border data exchange across business domains. The X-Road data exchange layer, administered by NIIS, is used nationally in Estonia and Finland as well as in data exchange between the countries.
But APIs alone cannot ensure the successful implementation of cross-border data exchange. As with TOOP, it also requires secure data exchange solutions, compatible data models, and semantic interoperability, as well as consideration of legal and administrative concerns. In many cases, this means drawing up agreements and contracts both between the countries whose authorities exchange data and between the parties that implement the data exchange.
Artificial intelligence
AI is on every government’s shopping list. It can be applied to customer service chatbots, anomaly detection, automation of business processes, and more. But AI solutions require data, whether public or personal, for a variety of purposes—to train machine learning models, for example, or to supply a chatbot with information on public services available in a particular area. Data sources must provide APIs to enable access to AI-based solutions. AI-based solutions may also publish their services to consumer applications via an API: Once a machine learning model has been trained, for instance, an application using the trained model can be published as an API.
The security, data models, and semantic interoperability concerns discussed earlier apply equally to AI-based e-government solutions. For example, in cases where AI is used to automate a decision-making process, all information must be correct, up to date, from trusted sources, and correctly interpreted. Moreover, the legal and ethical considerations can be way more complicated than the technical questions. AI use in government must be transparent: It should be possible to audit any actions taken and the reasoning behind them. APIs must also have sufficient security mechanisms in place, while processes and data flows across systems need to be traceable. A practical example of traceability is an HTTP header that contains a correspondence ID that’s included in all API requests and responses.
Technology tends to move faster than legislation. This sometimes means new technological innovations cannot be implemented right away because of legal restrictions; other times, new innovations are implemented, then banned or restricted later on. For example, while technology already makes autonomous vehicles possible, legal barriers prevent their widespread use.
Proactive public services
Traditionally, citizens initiate public service processes such as applying for a driver’s license. In cases where a process spans multiple authorities, a person may have to contact each authority separately. For example, applying for unemployment benefits in Finland may require registering as an unemployed job-seeker with one agency, then applying for the benefits with another. If that person is entitled to additional social benefits, such as Finland’s general housing allowance, they’d need to file an application with yet another authority.
Proactive public services are those a government provides or suggests to a citizen automatically. Governments already store a lot of information about their citizens; they’re usually aware of at least some aspects of a person’s current life situation, such as age and marital status. A government could proactively offer a day care placement to parents of small children, for example. Another example of a proactive public service is a prefilled tax declaration, wherein the tax authority gathers the necessary information from outside sources, such as an employer, instead of requiring the individual to enter those details manually. Citizens would then validate the prefilled information. If correct, they do nothing. If in need of updating, they can do it online.
Prefilled tax declarations also show the importance of data exchange between the public and private sectors. Without data from the private sector, such a service would not be possible, or would require additional effort from individual citizens. In recent years, this kind of data exchange between sectors has begun to shift from batch transfers toward real-time data exchange via APIs. The 2019 launch of Finland’s National Incomes Register was an important step in this direction. Finnish employers now report wage, pension, and benefits data to the register in near real time using APIs or other digital channels.
Human-centric data management
Today, most personal data management is organization-centric. Organizations, such as governments, collect and store the data, and they control who can use and access it as well as how. However, in 2015, a roundtable of experts invited by the European Commission to discuss personal data management began to formulate an alternative model called MyData.
According to this framework, all MyData is personal data, but personal data is considered MyData only if it’s controlled by the individual it describes. Citizens should have the right and practical means to manage their own personal data, the data should be technically easy to access, and shared infrastructure should enable its transfer and management. The aim of MyData is not to build one centralized storage space for personal data, but rather to create a distributed model. In such a model, data is stored in different information systems and registers that communicate with each other through APIs using standardized messaging and shared open infrastructure. Data flows directly between a data source and a data-using service. In addition, data sets are interoperable and portable between information systems and sectors, and individuals should be able to consent to (or refuse) the sharing of their data.
There is not yet a single, universally adopted MyData standard, but initiatives and organizations such as IHAN and MyData Global are actively working on it. Some MyData-enabled services are already available in both the public and private sectors. For example, in the Helsinki metropolitan area, students can get an automatic discount on public transportation tickets if they grant the Helsinki Regional Transport Authority access to data stored in KOSKI, the Finnish education registry. The Regional Transport Authority uses an API provided by KOSKI to verify whether an individual is entitled to the student discount. The authority is able to access the individual’s data if, and only if, that individual has allowed it. That means the education registry’s API must be able to control access on two levels: to the API itself, and to the data belonging to a specific user. The Finnish National Agency for Education owns the registry and controls access to the API, while the individual controls access to their data.
Essential, but not singular
APIs play an essential role in making e-government services possible, but secure data exchange solutions, unified data models, and semantic interoperability are equally crucial. After all, interoperability on a broader scale requires common standards, guidelines, and best practices, as well as collaboration across administrative organizations and borders and between the public and private sectors. Only when fit together can these puzzle pieces form a truly successful e-government solution, and all must factor into the design and implementation of thoughtful, effective APIs.