The Department of Veterans Affairs (VA) is using ethnographic approaches to designing Application Programming Interfaces (APIs) that connect more than nine million veterans to VA services. APIs are communication protocols that computer servers use to exchange information and that power everything we do online. When you book a flight on Google, an API communicates your choice between Google search and the airline. When you fill out a government form online, an API sends your information to the agency’s database. In the context of VA, APIs act as a secure front door to control and share data with and connect to veterans via laptops and mobile phones; assisting them in accessing VA benefits and services in a simpler, quicker, and more streamlined way.
APIs function as pipes that transmit information, but they are special kinds of pipes because they also translate people’s actions, needs, and personal stories into data that’s understandable, usable, and storable by complex information systems. Ethnography provides a critical analytical framework for API design to understand relations between people and things, how meaning gets produced in these interactions, and their limits (see Strathern 2018).
To better explain this connection, I’ll be using my experience working as part of the VA Lighthouse team, the VA’s API platform, to show how VA uses ethnography to map out a complex information and regulatory system and probe the translation limits of our API design. Like Dawn Nafus (2018) describes in the case of algorithms, an ethnographic approach to API design frees our team to first understand context and the larger picture of what we are designing for, instead of starting from narrowly scoped technical concerns that would miss this context.
A Closer Look at Government APIs
Government APIs are the behind-the-scenes technology that enables applications and their users to send online requests to government offices, transmit their personal information, and receive status notifications of pending requests. They’re also the conduits through which people’s requests move from one office to the next and through which decision makers communicate their decisions to the next touchpoint within a bureaucratic chain.
Similarly to paper documents, APIs “can be more like other material elements of bureaucracy such as chairs and desks than we typically think. For many genres of documents, it is often less important what they stand for than, like tables and desks, but how they arrange people around themselves” (Hull 2012, 134; emphasis added). In other words, government APIs are an integral part of digital infrastructure. Like other public infrastructure—think pipes, roads, cable lines, libraries, etc.—government APIs mediate relationships between people and institutions. Also like other types of infrastructure, APIs are embedded in larger structures, digital and non-digital, such as regulations, institutional processes, workflows, and database governance (Plantin and Punathambekar 2019). They are also embedded in contexts of use, meaning they help people and government agencies achieve tasks, and they facilitate the flow of information in these complex systems.
As with other infrastructure, APIs are not purely functional. They represent ideals of what a so-called “modern” government should look like and how it should operate. In the context of VA, APIs are part of a larger effort to modernize government by reducing the time and amount of paper required for veterans to access benefits and services and by making the process more transparent. Akin to other infrastructure projects (Özden-Schilling 2015), VA Lighthouse’s efforts to modernize follow a market logic centered around human-centered design, enhancing efficiency, reducing waste, and increasing trust.
VA Lighthouse: The Appeals API
We work closely with designers working on an API that enables veterans to digitally disagree with a VA pension or VA compensation benefits decision. Traditionally, veterans can only fax or mail their decision review request, which can be either a supplemental claim or a higher-level review request to VA’s Veteran Benefits Administration. They navigate a complex regulatory system that encompasses two parallel appeals processes. On the one hand, there’s the legacy appeals process for when a veteran disagrees with a decision made before February 19, 2019. On the other hand, there’s a new process established by the Appeals Modernization Act of 2017 (AMA) that applies to decisions made on or after February 19, 2019. AMA was implemented to modernize the way veterans submit a claim for a decision review. AMA aims to cut the time and increase transparency by delineating clear-cut decision review lanes.
In line with the AMA mandate to streamline the decision review process, VA designed the Appeals API to provide a digital channel for veterans to submit their decision review claims online. The Appeals API automates some of the steps involved in intaking a new decision review into the VA system, and it provides a digital trail to track a decision review’s status. Similarly to what Richard Pope (2019) terms “government as platform,” the Appeals API integrates with different VA systems to share data, instead of copying data into multiple databases. This new design requires an understanding of how information flows from system to system, the rules that govern data validity for each system, and the role of human interpretation in validating data.
We spent several months researching this context for one of the AMA decision review lanes: the Higher-Level Review (HLR). Veterans can file an HLR to request a de novo review, meaning a second review from a higher-ranked VA review officer of the same evidence used in the original decision. Veterans have one year from the date of a claim’s decision to file an HLR if the date of claim is on or after February 19, 2019. We interviewed veteran representatives and lawyers, who usually file disagreement claims on behalf of veterans; intake officers who input the forms into VA’s digital systems; reviewers; and administrative staff in charge of communicating decisions to veterans. We compared those interview notes with process manuals and participated in meetings with the VA office that “owns” the HLRs. Using this information, we created a workflow diagram that maps the people, tasks, and systems involved in processing HLRs.
The ethnographic data we collected revealed that the HLR process distills veterans’ injuries and disabilities incurred in military service into data for a veteran’s disability claim that’s legible to VA systems (for an ethnography of veterans’ experience see Wool 2015).
As we heard from veteran representatives and lawyers, most of their work involves understanding veterans’ military-related disabilities and assisting them with submitting claims and obtaining evidence, such as military and medical records, that substantiate those claims.
Once a veteran or veteran’s representative files a claim, a claims assistant establishes the claim within the VA's intake system. This work entails checking dates to ensure the HLR is eligible and routes the claim to a decision review officer to review the veteran’s record, hold an informal conference if requested on the form, and issue a decision. A veteran service representative then generates a notification letter for the veteran documenting the grant or denial, providing information regarding their options if they disagree with the HLR decision.
Validating Data through APIs
We designed the Appeals API to automate some data validation tasks, but we soon found the limits of translating VA’s data validation logic into API form. We built features to automatically check for eligibility, like validating dates and veterans’ file numbers, which would reduce errors in intake, alleviate the claims assistants’ workload, and ultimately shave days off the whole process for veterans. This part was straightforward.
Difficulty arose when we tried to automate tasks involving human interpretation and judgment, like determining whether a disability claimed under the legacy appeals process is eligible under the AMA process.
Automating human judgment can backfire spectacularly. As Virginia Eubanks (2018) shows in Automating Inequality, the automation of social services faces the very real risk of permanently encoding biases like racism, classism, and sexism with devastating consequences for the communities that rely on these services. Albeit imperfect, human review offers opportunities to dissent, challenge, and modify cases. Cognizant that APIs cannot (and should not) replace human interpretive labor, we designed the Appeals API to facilitate information verification among canonical databases. We also proposed tweaks to the review process to give veterans opportunities to verify the information VA collects at the front-end of the process with the aim of making it more transparent. This work is ongoing and has involved extensive conversations within VA.
Anthropologists studying big data and datafication—or turning many aspects of life into data—have called attention to the role of ethnography in demystifying data as “closed and fixed objective evidence” (Pink and Lanzeni 2018, 2). Ethnography’s emphasis on practice—how data is collected, processed, and made relevant, by whom, and to what end—reveals opportunities for individuals to have more of a say in the collection and use of their personal data, what Minna Ruckenstein and Natasha Dow-Schüll (2017) call “agentic possibilities.”
In the context of the Appeals API, an ethnographic approach has focused on understanding our stakeholders’ points of view, practices, and internal processes and has helped us understand the complexities and nuances of what we were designing. We focused on understanding the regulatory process in which the API would be embedded. But in doing so, we learned about the people and practices involved in translating veterans’ claims into data points that could easily flow through VA systems. This process of translation, as any other form of translation, is prone to honest misreading and misunderstandings. We designed the Appeals API to give more opportunities for veterans to clarify the information in their case. The results are enhanced and more efficient claims processing for VA employees and veterans.
As digital technologies increasingly mediate the relationship between people and government agencies, ethnography has the tools to understand the types of relationships digital technologies are building, and the translation work required for these relationships to work. Consequently, ethnographers can play a key role in developing software design that includes opportunities for citizens to play a more active role in relation to their data.
Eubanks, Virginia. 2018. Automating Inequality: How High-Tech Tools Profile, Police, and Punish the Poor. New York: St. Martin’s Press.
Hull, Matthew S. 2012. Government of Paper: The Materiality of Bureaucracy in Urban Pakistan. Berkeley: University of California Press.
Nafus, Dawn. 2018. “Exploration or Algorithm? The Undone Science before the Algorithms.” Cultural Anthropology 33, no. 3: 368–74.
Özden-Schilling, Canay. 2015. “Economy Electric.” Cultural Anthropology 30, no. 4: 578–88.
Pink, Sarah, and Debora Lanzeni. 2018. “Future Anthropology Ethics and Datafication: Temporality and Responsibility in Research.” Social Media + Society 4, no. 2.
Plantin, Jean-Christophe, and Aswin Punathambekar. 2019. “Digital Media Infrastructures: Pipes, Platforms, and Politics.” Media, Culture and Society 41, no. 2: 163–74.
Pope, Richard. 2019. “Playbook: Government as a Platform.” Ash Center for Democratic Governance and Innovation.
Ruckenstein, Minna, and Natasha Dow Schüll. 2017. “The Datafication of Health.” Annual Review of Anthropology 46, no. 1: 261–78.
Strathern, Marilyn. 2018. “Relations.” Cambridge Encyclopedia of Anthropology, May 30.
Wool, Zoë H. 2015. After War: The Weight of Life at Walter Reed. Durham, N.C.: Duke University Press.