Case Study

Intro

Nava worked alongside Montana to help build an Application Programming Interface (API) prototype to help ease the process of managing participant data for Montana WIC’s staff, and to inform a national API standard that would break down systemic barriers to WIC modernization. This prototype was part of a 6-month demonstration project made possible with support from Schmidt Futures, a philanthropic initiative founded by Eric and Wendy Schmidt. The other component of the project involved building an eligibility screener tool, explained in this case study, which sought to make it easier for people to apply for the state’s WIC program. Through building and testing this API prototype, we learned how we might overcome system barriers to interoperability in WIC agencies across the country while helping Montana enroll more eligible people into WIC. 

Approach

In 2020, Nava published a landscape report with the National WIC Association (NWA) to understand how COVID-19 and a shift to remote services impacted how WIC participants enrolled and received benefits, and how WIC staff facilitated these processes. In that report, we identified interest from WIC staff across the country to continue offering remote service options to help ease the process of enrollment for WIC participants. Yet many WIC agencies lacked the tools that made integrating these options less burdensome. Through this demonstration project, we prototyped two digital tools to build understanding towards interoperability—or enabling information exchange between different technological systems—for a future WIC.

A common barrier we’ve identified in our research is that WIC programs, which are operated individually by state and local agencies, must accommodate a fractured system of different databases, digital tools, paper records, and manual tools. Each state has a central management information system (MIS) that serves as the case and benefits management system for the program, holding information not only about participants but about WIC-eligible food products and more. However, not all digital tools are integrated with this system. 

When it comes to navigating multiple siloed systems, Application Programming Interfaces, or APIs, are an excellent solution. An API, or "Application Programming Interface" is a technical term for a way that one computer system can talk to another. APIs connect disparate, fractured systems, allowing agencies to adopt new tools or practices without having to build custom software. An API standard, meanwhile, is a shared, well-defined format for implementing an API, allowing multiple different computer systems to have a shared way of talking to outside systems. With a vision for a national API standard that could empower WIC agencies across the country to employ digital tools, we set out to learn how we could integrate an API prototype with Montana’s MIS system and in the process, understand the challenges and opportunities for a national standard.

Alongside our government partners, we built a prototype for a mobile-first eligibility screener web application and an API prototype to connect that enrollment data with Montana’s MIS, M-SPIRIT. Our API prototype accepted data from the eligibility screener using an API, mimicking how an MIS could directly receive data from external tools.

Through this work, we gained a deeper understanding of MIS platforms generally, whether an API standard would be valuable and feasible for WIC, and what might need to happen to achieve a national API standard. 

Outcomes

Our demonstration project results further cemented our belief in the power of a national API standard for a variety of reasons. First, our user research showed that participants yearn for a more hybrid, online and offline, experience with WIC. Recent research also suggests that a hybrid delivery model would be effective and well-liked by participants. One recent study found that most WIC participants were satisfied with remote service delivery, while a research brief from FNS says that “Nearly all State agencies reported that the physical presence and remote benefit issuance waivers ultimately made WIC safer, more accessible, and more convenient for participants’ schedules and a large majority reported that the two waivers improved access to food during the pandemic.” More easily being able to share and transfer data between tools can accelerate WIC agencies toward this type of user experience. 

When it comes to data, Montana's MIS does not have any functionality for importing or exporting data. Instead, Montana's IT department created workaround procedures to transfer data from tools into M-SPIRIT. This is not only brittle, but also burdensome for staff. Currently, Montana WIC staff must either create elaborate workarounds or manually copy data by hand to transfer any data generated from potential participants by an application or enrollment tool to the MIS. 

An API standard could preserve the MIS as the source of truth—meaning the organization pulls data from this particular, accurate source to help prevent errors or confusion from multiple data sources—removing the need for manual entry or custom workarounds.

Process

Montana's MIS, M-SPIRIT

Learning about and understanding how Montana's MIS, M-SPIRIT, worked was a key goal of our project. In order to understand interoperability for a future API standard, our project included an API prototype that demonstrated what API integration with an MIS (M-SPIRIT) would enable. We reviewed key functional documentation, including the Detailed Technical Specification Document, to understand how M-SPIRIT handles, maintains, and stores data and how we might be able to interact with that data for a future API.

An example screen from SPIRIT Classic, the desktop version of M-SPIRIT. This page displays the initial contact functionality captured during "applicant pre-screening" - when a record is first created in SPIRIT.

We also reviewed the base of research we had already produced for the landscape assessment about MIS platforms, and we dug into other available tech specs for related systems, such as EBT, FNS, and state requirements for MIS platforms. To inform our project and our understanding of the technical capabilities of M-SPIRIT, including the ongoing development of a web-based version of SPIRIT, we interviewed technical stakeholders from Montana and the SPIRIT User Group.

We examined both the desktop version of M-SPIRIT and an in-progress test of the web version to understand its core functionalities as defined by FNS legislation, regulation, and policies. We learned that M-SPIRIT can import and export data related to Electronic Benefits Transfer (EBT), but that it is not able to import or export other data. In order to integrate other third-party applications, Montana WIC used powershell scripts and SQL Server stored procedures to directly extract data from the database. We learned that if we wanted to directly integrate with M-SPIRIT, we would have to leverage a similar process.

Product concept

At the onset of our project, we had the following high-level vision: 

Our early high-level product vision.

In this early product concept, we imagined that a participant would interact with our eligibility screener tool prototype by answering some questions on eligibility, and that they’d have a way to submit that data (read more about our eligibility screener here). An API prototype would then facilitate the data transfer from the eligibility screener to M-SPIRIT, but we didn't yet know how exactly that would be done. 

We started by assuming the eligibility screener would only interface with the custom-built API prototype instead of directly interfacing with Montana's MIS. At this point, we didn't know what kind of existing API or data import/export capabilities Montana's MIS would support. The idea was to mock out what an API could accomplish if it were built into the MIS. The API prototype’s intention is to pretend that it is the MIS, simulating the experience of an MIS with an API. 

Finally, we knew WIC staff would have to see this eligibility information so they could take the next step of reaching out and scheduling a certification appointment, but didn't yet know what that would look like in process or as a product interface.

Mapping out a minimum viable product (MVP)

We started by researching both participant and WIC staff needs and expectations through user interviews as well as previous research from other organizations in this space. Using this, we built out a service blueprint to capture how user inputs, staff processes, and different systems all supported how Montana WIC serves participants. Clinic staff told us they wanted to speak directly with prospective participants and validate their eligibility information before entering any data into M-SPIRIT. M-SPIRIT is the source of truth for Montana WIC: the clinic staff we spoke with do not use M-SPIRIT to hold "pending" applications.

Additionally, our research helped us understand the technical capabilities of M-SPIRIT and how it organized information. We scoped out the information we'd need to include in a screener, and decided that the best way to showcase what an API standard could do would be to have the API prototype act as a data pass through from the screener to M-SPIRIT. The screener would connect to the API prototype, which would take in the applicant-submitted data from the screener and convert it into a CSV file. That CSV file would act as the pass through, carrying the participant’s data from the screener into M-SPIRIT.

We looked into a few options to replicate a "connection" between the screener and M-SPIRIT: 

A diagram of different options for the Mock API MVP data transfer.

For each option, we considered:

• Would the proposed workflow be an intuitive and easy process for WIC staff?

• How does this process fit into WIC staff’s existing mental model?

• What are the security and personally identified information (PII) constraints?

• How scalable is the solution beyond Montana?

• What is the technical effort required compared with the anticipated outcome?

Ultimately, with our Montana stakeholders, we decided that for the purposes of the demonstration MVP, our scope would consist of sending the CSV file containing screener data to WIC staff via email. We knew from our research that both email and Excel are known tools for staff and are used in their processes currently. Additionally, we knew that clinic staff wanted to validate an applicant’s eligibility before entering it into M-SPIRIT. If we were to insert new data—potentially eligible, but not certified—into M-SPIRIT, that could make the process more burdensome for staff and potentially pollute the database of WIC participants for the entire state.

The scope of this project allowed us to test and learn more about a potential API standard. We did this by building out an API prototype that generated a CSV file, then observing how staff interpreted and used that data. Our CSV file matched fields in M-SPIRIT, therefore verifying that the correct data could be directly entered into the correct fields in M-SPIRIT. The API prototype also helped WIC staff by providing them more accurate information submitted by prospective participants. We used what we learned to brainstorm how we might eventually move this data over to M-SPIRIT (perhaps something like a staff-initiated "send" action).

Developing the API prototype

We architected a distinct, stand-alone API that acts as if it were a modern API wrapper around M-SPIRIT. We wanted to demonstrate what a modern, RESTful API for an MIS could look like. For the purposes of our demonstration, we defined one endpoint—the way that an API sends or collects information between systems—in the API prototype to accept the data collected by the eligibility screener.

A screenshot of data transfer code demonstrating the fields that the API prototype expects to receive from the eligibility screener.

By developing this data interface as an API endpoint, we separated out the information gathering tool (the "how") from the data transfer itself (the "what"). For our demo project, our "how" was an eligibility screener that a potential WIC participant fills out themselves, and our “what” was the data transfer through the API prototype. However, if an MIS provided this API endpoint, any application that gathered the required information—such as an SMS-based enrollment tool that we explored during concept testing—could be used to supply this information (the "how") to the MIS.

We wanted the API prototype to be a lightweight implementation for demonstration purposes, yet robust enough to serve as a foundation for future API standard explorations. To serve both of these goals, we chose to build a Python-based Flask API. We chose to use a PostgreSQL database as our persistent data store, and we described our API using the OpenAPI Specification. These tools allowed us to build an API quickly, while knowing our foundation was secure, reliable, and flexible.

To support our MVP scope of sending a CSV via email, we wrote a script that exports collected entries as records in a CSV file. Like the eligibility screener, the API prototype was architected so that it could be built as a Docker image and deployed as a Docker container. The CSV generation script was written so that it could flexibly interact with the application however it was deployed. In our case, we added support for running the script as an AWS ECS Task.

A flow demonstrating how the API prototype converts the user-submitted data to a CSV.

Conclusion

Building this API prototype proved to us not only the potential power of using APIs with WIC technology, but also provided some guidance on how to move forward with researching and building a national API standard. Our initial research shows that an API standard would need to:

• Define data structures, formats, and endpoints that enable features and functionality

• Establish a governance structure, governing body and decision-making framework for ongoing development and accountability

• Build out standards and guidelines and provide environments, documentation, and support for developers implementing API standard and other tool functionality 

• Define versioning and access permissions around the API and its data

• Require tools and systems in the WIC ecosystem to implement according to the standard, and have a way to measure and monitor API adoption 

We also learned that many of the workaround solutions WIC staff are forced to use when interacting with M-SPIRIT are fragile. In our technical research, we discovered that M-SPIRIT doesn’t have a way to import or export data beyond how it handles EBT information. In order to manage data transfers, staff have developed a workaround using Tableau. 

This flow demonstrates some workaround processes WIC staff use to transfer data between third party tools and M-SPIRIT.

We discussed using Tableau to transfer our screener data, but staff told us that their process was brittle and required a lot of handholding: checking and pushing the scripts that enabled the process. Staff had also remarked that because this was a workaround using a third party tool, it wasn't clear how long this process would be active, especially if there is IT turnover. Institutional knowledge is lost through attrition, especially for custom solutions like this Tableau data transfer, providing yet another reason for why APIs could help make WIC staff’s work processes easier.

Moving forward, we want to learn more about how much one MIS can deviate from state to state. For example, does Alaska's version of SPIRIT differ from Montana's version of SPIRIT? Is there also deviation within a state agency, or in how local/county IT handles installation and maintenance? And at what level does regular data transfer occur? Investigating answers to these questions could open up opportunities to think about how to improve business processes and data transfer in support of an API standard.

Special thanks to Sasha Reid who is serving as a Solutions Architect on this project and contributed to this article.