“When federal policy changes, we say, “oh my god, we’ve got to reprogram.” We go back to the vendors and have to put in a change order. It’s a terribly inefficient process.”
— A state technology leader interviewed by the Eligibility APIs Initiative
Human services agencies need to continually update their benefits systems when policy changes, new risks emerge, or new needs arise. This is risky, time-consuming, expensive work.
It is also duplicative. Agencies often need similar functionality or updates—such as when a new federal law must be implemented across all states and territories. But agency systems are typically unique and separated from others. Updated policy or functionality in one system rarely propagates to other systems.
The connections it makes to other systems are also incredibly valuable. Connected systems can share policy, information, and code and can present a more coherent and streamlined experience to the public.
Systems can be connected together in different ways: through Application Programming Interfaces (APIs), through shared software libraries, or by publishing eligibility rules as open-source computer code.
Systems that are designed to communicate with each other can do things that siloed systems can’t:
- Centers for Medicare & Medicaid Services (CMS) has used APIs to help beneficiaries, health care providers, and researchers coordinate care and securely share important patient information.
- The Veteran’s Administration (VA)’s API platform allows veterans to easily view their VA health records together with all their other health care records inside the iPhone Health app or on their Android devices.
The human services eligibility space faces several challenges that could be productively addressed by systems that are designed to communicate with each other:
- Applicants are often eligible for more than one benefit, and interact with more than one system.
- Programs often have overlapping, or similar eligibility criteria to each other.
- Policies change continuously—and sometimes unpredictably—with grave consequences to programs and beneficiaries if systems fall out of sync with the law.
Designing systems to communicate with each other (an "API-driven" approach) could mean that:
- An updated policy can propagate through multiple systems without each of those systems needing to individually code it themselves; agencies can update individual pieces of their system without having to modify the entire system;
- Different systems can share information instead of requiring beneficiaries or program staff to enter the same information multiple times;
- Agencies with similar informational or functional needs can pool their resources to build and maintain shared tools instead of each building their own unique, incompatible solutions.
Benefits to agencies:
| Status Quo | Using Eligibility Services | |
|---|---|---|
| Policy updates | When federal policy changes, updates are carried out using change orders, which can be slow and expensive. | Could allow systems to consume new rules directly, removing the need for change orders. |
| Accuracy | State agencies do their best to interpret federal rules. | Federal agencies could publish rules directly as code, removing the need for states to interpret their rules. |
| Security | States carry sensitive data and documents to verify eligibility. | An eligibility response from a federal agency could serve the same function, removing the need to carry sensitive data or documents. |
We conducted research with government agencies, created sample procurement language, and built prototype software to help agencies explore these opportunities. See below for resources that will help your agency put these techniques into practice:
Have feedback, suggestions, or questions about how to implement these ideas? Get in touch at [email protected].