A Reference Model for Service-Based/Modular Integrated Eligibility

In my last blog I discussed about Service-based or Modular Integrated Eligibility system and how it can help states build an integrated yet flexible technology landscape supporting all health and human services programs.

Let’s look at the key blocks of a service-based IES that can help design a common reference HHS architecture.

Design principles

• Compliance – Compliant with government regulation and standards like NIST SP800-53, CMS TRA
• Modularity – Decouples business functionality from monolithic architecture. Decomposes business processes to lowest level, preferably micro-services
• Scalability – Supports increases in capacity on an episodic and long term basis
• Portability – Enables movement from one platform to another platform and/or on- premise to hybrid to cloud without a need for any redevelopment or re-eingeering
• Platform Agnostic – Not completely technology agnostic as CMS/HHS have declared technologies that should be used, such as an external rules engine, but platform agnostic and implementation agnostic

Standards Alignment

• MITA alignment – Offers a layer that corresponds to the MITA access channels and uses a service gateway and multi module configuration to enable a services infrastructure, with discrete business services (workflows, rules, and processes) enabled by specific technologies (e.g. rules engine). Provides interoperable technical services through a series of frameworks (Notices, Document Management, etc). And, delivers interoperability services as another access channel, enabling a unified security approach and avoiding a “side door” interoperability into the application layer
• NHSIA alignment – NHSIA focuses on shared business processes across HHS systems such as Eligibility, HIE, etc. Service-based IES should enable this through the concept of modular business processes in its application layer, which can be as granular as an identity matching micro-service or as large as a case management business process, which can be linked through services to provide the required application functionality. Shared infrastructure is supported at the data layer through the use of an Operational Data Store, integration through master data technologies, and aggregation into a data warehouse with data marts to support the operational and strategic intelligence needs of the agency. Security is supported through a security layer enabling Identity and Access Management as the gatekeeper to the access layer.

Layers

• Security – Service-based IES puts the focus on security as the gatekeeper and helps focus implementation on that as a primary goal, along with depth of security throughout in the use of zoned firewalls, FIPS-140 compliant encryption of data in transit and at rest, and sufficient technologies to defend the system. In particular, Service-based IES calls for the use of an Intrusion Protection System to mediate the effects of zero-day exploits and a security information and event management system to enable auditing, problem resolution, and accountability.
• Access – The system can be accessed from two channels: Internet and intranet. Both classified as external to the trusted system and pass through the security layer. This enables organizations to mitigate the effects of intranet systems being the source of security failures. Access can be broadly classified as EDI (Electronic Data Interchange), which can be an exchange automated by an internal or external actor, and portal based, which provides humans with access to the system. EDI can be sophisticated web-services gateways exchanging data in advanced formats such as National Information Exchange Model (NIEM), or as old-fashioned as faxed documents. The abstract treatment is the same – pass through security and reside in a DMZ waiting for the application layer to decide what is to be done. The whole access layer is firewalled from the rest of the system.
• Application – The application layer contains the largest number of components and the most complicated architecture. At the highest level, it provides business services that can be consumed by a portal technology, or shared via EDI gateways. Underlying these logical business services is an API gateway that provides the technical services. Below the gateway, modules from various applications, vendors, and platforms provide business processes that can be orchestrated via the API gateway or passed to the portal as business services. The logic of the business processes is externalized through Workflow Management, Business Process Management, and Rules Engines. Items susceptible to real world change, such as workflow or rules, are externalized. Underlying the business processes, and supporting MITA-style technical services, are a variety of frameworks that enable and present a vendor agnostic layer to enable the use of the technology of choice for areas like document management, notices, batch, etc.
• Interoperability – Interoperability is a function tightly coupled with the application processes. Meta data and service registries enable interoperability between systems both at a transport and semantic level: data or services can be universally located and harmonized via interoperability services. Data abstraction below an interoperability level assures incremental, modular data stores. Data stores may operate as natively required, but the data integrity and meaning will be mapped as the business requires. Underlying the data abstraction and meta services is the Enterprise Services Bus (ESB) that enables transformation services.
• Data – Data is firewalled from the application layer to facilitate access control and minimize risk. Individual business modules can store data as required to perform their function. The data is aggregated and normalized into an Operational Data Store to enable a single source of truth for the enterprise. Operational data is transformed and transferred to a data warehouse, where it can be used for operational and strategic decision support. An arbitrary number of data marts can be created to facilitate data use for a specific purpose, by specific classes of users, or to enable more timely views with a mind to performance.

Practical Use of Reference Architecture

Service-based IES can serve as a benchmark to design any HHS system. By following the patterns contained in the Service-based IES, HHS agencies can ensure alignment with federal standards and guidelines such as NIST, NHSIA, and MITA. Modularity, including multi-vendor and multi-platform, is supported at the data and application layers, with the service gateway and Access Layer providing the glue to present a user-centric methodology.

Layers can be abstracted, through use of on-premise, Platform-as-a-Service, or integration of cloud platforms, as needed, replacing modules or the application and data layers. Scenarios where all three zones are cloud based in whole or in part are possible, with the integration points being at the data and access channel boundaries.

Devolving the Service-based IES into an application, information, or data architecture becomes an exercise of zooming focus on a Service-based IES component, providing the detail needed to develop code or configure a tool. It should not require the addition of a component as the Service-based IES is meant to be a holistic approach to the requirements of all HHS systems.

Conclusion

Service-based IES offers a powerful architecture to develop a modern, modular, loosely-coupled and scalable HHS IT landscape that enables agencies to shift focus from IT to their core mission of improving outcomes and care and reducing cost.

Implementation of Service-based IES relies on modern technologies that are used in the commercial world today: platforms, data federation and master data management, externalized business rules and externalized business processes. A base set of functionality exists, but can be easily replaced or overwritten as needed. The core is truly loosely coupled, which enables each layer and program to operate independently, but integrated with the data for the citizen.

Author Details

Richard Brady

Rick leads the Government Healthcare practice at Infosys for the US and Canada. He has 20+ years experience in healthcare and public sector.

Related Reading

• What is Cloud Oracle ERP - Glossary
• What’s Next for Health and Human Services - Podcast
• Integrated Eligibility System