Public Sector

Traditional Integrated Eligibility systems encapsulate complex rules for the determination of program participation and manage the lifecycle of the program participant -- enrollment, change in circumstances, reenrollment, etc. -- through case management software. These systems are tightly integrated between programs and technologies. Older systems include business logic in all the three application architecture layers: User Interfaces, Business Logic, and Data Storage. This leads to long-duration implementations as dependencies must be carefully documented and the impact of any changes must be carefully assessed and tested in detail.

This is a major barrier to enabling the business processes ideal for an organization's specific requirements and the regulatory environment. It is often heard that the organization must fit the system's "out of the box" functionality. Change is feared, expensive to implement, and results in errors in production that give rise to lawsuits, worker frustration, and degraded service. Regulatory change is not implemented in the systems and the citizen's interest deferred to technology complexity. This is not appropriate or desirable.

Potential solutions to improve agility

A variety of approaches have been taken to solve the problem of rigidity in systems which prevent change and optimization.

Dis-integrating eligibility - allowing departments and their programs to implement their own systems. Some states include a central repository to link citizen ID across programs. This increases flexibility and reduces complexity for any given program, but results in multiple systems serving the same population which increases the chances of fraud, reduces program coordination and negatively impacts service delivery.

One system for everything - traditional eligibility, child welfare, adult protective services and all social programs. This approach assures tight program integration and maximizes dollar investment, but at the cost of flexibility and the associated risk of error while incorporation of any change. Any variance for a particular location, such as a county, must be hard coded into existing rules and programs.

Designing a Service-based integrated eligibility system

A preferred solution is to modularize components, both in the application architecture (user interface, business logic, data storage) as well as the program and government or organizational unit (e.g., state, county, city, service center). This solution balances program independence and integration to ensure maximum citizen value.  Each program shares a common platform and a set of tools, but is also able to implement the rules and processes required for its particular circumstances. We call this a service-based integrated eligibility system (IES).

Designing a Service-based IES

A Service-based IES is a classic N-tier architecture that includes specific technologies (e.g., rules engine, workflow engine) where federal preferences or requirements exist. It includes the classic presentation/application/persistence model while incorporating requirements for loosely coupled systems and modularity.

This can help develop a reference architecture for Health and Human Services (HHS) and provide a unified technology view of a diverse set of federal design guidance and requirements. While there are state-specific and/or program-specific requirements, quite a few common tools and patterns exist that can be reused by multiple states. By developing a unified HHS architecture, states can take advantage of economies of scale and reuse, enabling higher efficiencies, reducing training costs, maximizing the use of technology investments, and accelerating implementations.

Check out my next blog to know about the key building blocks of a service-based or modular IES.