Global Case Management & Food and Nutrition Services Integration. State of North Carolina

Transcription

1 North Carolina Families Accessing Services through Technology Global Case Management & Food and Nutrition Services Integration Category: Improving State Operations Contact: Wendy Keller Phone: State of North Carolina N.C. Department of Health and Human Services (NC DHHS) Project Initiation Date: August 2009 Project Completion Date: December 2012

2 1. Executive Summary The North Carolina Families Accessing Services through Technology (NC FAST) Program improves the ability of NC Department of Health and Human Services (DHHS) and social services departments of 100 counties to serve the citizens of NC. NC FAST introduces new technological tools and business processes that free staff members from administrative tasks, enabling them to spend more time assisting families. The first project in the multi-phased program integrates Food and Nutrition Services with a Global Case Management system. The framework and processes developed for this phase will be applied to subsequent NC FAST projects to improve efficiencies and reduce costs. North Carolina DHHS supervises the human service programs administered by the 100 county departments of social services, many of which are federally initiated programs dating back to the 1970s. In the early 1980s, North Carolina developed automated mainframe systems to support these programs that have evolved and changed to accommodate related programs and rule changes over the years. The NC FAST program identified nineteen legacy systems that collect, maintain and process applicant and recipient data. Although a solid foundation, the legacy systems are disparate and not well suited to support the growing demands of economic benefits, child welfare, adult care and aging services, health insurance reform, and changes in accountability to share and integrate data. The NC FAST Case Management solution represents the first steps toward improved operations for NC DHHS social services: Real-time sharing of client and case information across program and county lines. Reduced cycle time for eligibility determination. Automated collection and maintenance of client demographic information including client relationships, and data to manage, record and track service plans. NC FAST directly supports the State Chief Information Officer and the Governor s goals to improve efficiency through information technology in North Carolina. The tools and processes developed for this solution will reduce costs and lower development times. For the first project s Operations and Maintenance phase, 2 full time staff support over 16 services and 36 operations, as well as development for new exchanges. As NC FAST collects data on reductions in development times for new exchanges, a more analytical savings assessment will be performed; however, initial assessments indicate that a smaller pool of developers has supported a larger workload. 2

3 2. Description of the Business Problem and Solution The NC FAST Case Management solution supports the human services and economic benefits programs supervised by NC DHHS. In deploying NC FAST, the state encountered a large number disparate systems that were not integrated, supported different subsets of the state s requirements, and were developed using a variety of platforms, programming languages and products. The resulting business complications include: Disparate systems and platforms making inter-system communication difficult. The systems developed to support NC DHHS business needs were housed on a variety of platforms, developed without a common approach or language, and supported by a variety of products. It was difficult to facilitate communication and data exchanges between systems. A large number of point-to-point interfaces with little to no reusability. Due to the disparity in systems that exchange case information, development teams created point-to-point interface transformations with little reusability and higher manpower and maintenance requirements. Whenever systems or requirements changed, the interface had to be recoded to support the new exchange. Long development cycles. The custom nature of the exchanges resulted in longer development cycles, higher resource costs, and less reusability. Lack of consistent controls for processes (security, logging, authentication, authorization, transformation, governance). Due to siloed development of custom solutions, there was a lack of consistency and controls required for audit and oversight functions, which, when applied, were not reusable across systems to ensure all systems maintained these processes at the correct, appropriate level. Lack of a consistent language and taxonomy. Underlying all issues previously listed was the lack of a consistent exchange language. For example: o Data elements. Different systems defined data differently (e.g., a male client may be referred to as 01 or M or Male ). o Common business taxonomy. The core data grouping within NC DHHS is the case; different divisions defined a case differently, resulting in confusion when exchanging whole or partial cases. o Lack of common data exchange model. Differences in data formats and encoding (i.e., ASCII, EBCDIC) resulted in complex transformation processing. No common data transport. Lack of a consistent data transport protocol or toolset resulted in the implementation of a variety of protocols such as FTP, SFTP, FTPS, SCP, MQ Series, and a variety of tools such as Connect:Direct. This resulted in added costs, and an inconsistent application of authorization, security and governance as data travels from system to system. 3

4 3. Significance to the Improvements of the Operation of Government The state embarked on the NC FAST Program to consolidate legacy mainframe systems. This consolidation includes significant rework of business processes and, more recently, the state s compliance with the Affordable Care Act, which significantly accelerated timelines. The positive impact of the NC FAST consolidation work simplicity, transparency, commonality, ease of use will be felt and realized across the state of North Carolina for years to come. Based on aggressive timelines and the phased consolidation of the legacy systems, the state implemented an Enterprise Service Bus (ESB) to facilitate both the long term integration and data exchange requirements, and to bridge the gap when the legacy systems would need to continue to exchange information with NC FAST. Once the base ESB and data model were selected, the state designed a common software architecture called the Generalized Common Flow (GCF) as shown in Figure 1. The GCF was designed and developed with the following guiding principles in mind: Framework not System. The GCF provides a framework into which business processes can be implemented. It is not a functioning system, but a collection of technical components, which when configured can process data consistently. Configuration not Development. The GCF is developed with the concept of configuration to enable business processes and data exchanges, not development. Developers no longer need to write extensive code to implement an exchange. This principle is also driven by the lack of experienced JAVA developers. By reducing the skills needed to configure an exchange, the state broadens the base of available developers while reducing cost. Reduce Development Time. A significant design driver was creating a framework that would allow significant reductions in development cycles. The GCF Configuration not Development principle is driven in part by this requirement to reduce overall effort involved in creating interfaces. Standardized Framework means Generalized Troubleshooting. By providing a standardized set of framework components, the ability to troubleshoot unique exchanges is also generalized. No longer does the developer of a particular exchange need to lead the effort to troubleshoot a defect. Reusability. This principle is at the core of GCF design. Being able to reuse consistent technical components regardless of the exchange is key, as well as being able to meet aggressive schedules and maintain low costs. 4

5 Figure 1 NC FAST ESB Implementation NC FAST ESB Implementation GCF Components ESB System Component Provider Systems Log 4 J epass DB NCID Log 4 J Adapter Logging Authentication Governance and Authorization Availability Transformation and Patterns OUT External Systems Transformation and Patterns IN Filtering Logging Adapter epass DB WSRR Generalized Common Flow Figure 1 shows how the GCF provides a framework of services. The aforementioned issues around inconsistencies in the development of supporting technical services such as logging, governance, authentication, transformations, etc., are managed by the GCF by including these core services as part of the framework. Developers no longer need to develop these components, but only to configure code to leverage existing components. 4. Benefits of NC FAST (Financial and Non-Financial) Benefits of implementing the GCF to facilitate and manage data exchanges between systems can be defined by revisiting the Section 2 business problem statements: Linked systems and platforms. Using the ESB and GCF as a mediation broker between systems enables systems on disparate platforms to communicate without modifications to source or target systems. Through the broker a single interface from a source system can be used by many target systems without the need to rewrite code on the source system. All transformations are facilitated through configuration within the GCF. Seamless exchanges and reusability. Using the ESB and GCF point-to-point interface between systems can be eliminated. While mappings may continue to be unique to an exchange, the patterns used in transformations are common and facilitate reuse. All other components of the exchange are GCF components and are by their design reusable components. Shorter development cycles. Using GCF components, much of the work to implement a new data exchange is in the configuration, mapping and transformation 5

6 of source data to target systems. Development of technical components required to support the interface (e.g., authentication, logging) are managed by common components within the GCF. This greatly reduces development times required to implement new interfaces. Changes to a source or target system are abstracted from the exchange itself. These changes simply require modifications to the transformation or mapping configuration. Process controls. The GCF by its design addresses and eliminates these inconsistencies. These technical components are standardized across exchanges and are merely configuration items for the interface developer. Consistent language and taxonomy. Adopting the NIEM model addresses these issues. While all transactions that use the ESB and GCF are NIEM compliant, the team acknowledges adoption periods required for legacy systems to use the model, and the business case of not modifying a system that is close to its end of life. As such, the team provided a mechanism to transform these inbound requests prior to entering the ESB. As shown in Figure 1, the team developed adapter layers at ESB end points that transform inbound requests from their source data model to the NIEM model prior to entering the ESB. This in turn abstracts all transformations of disparate data models to NIEM. The team expects that over time source and target systems would either adopt the NIEM model or implement application logic to be able to accept and transform a NIEM message as part of their end of the data exchange, thus allowing deprecation of adapter code. o Data elements. NIEM standardizes data element naming and attributes. o Common business taxonomy. Through both the NIEM model and extensions developed by NC FAST, a common business taxonomy has been developed. o Common data exchange model. Adopting the NIEM model resulted in a common data model and schema used by all data exchange partners. NIEM uses a canonical XML-based schema. Issues related to communications between disparate platforms at various ends of the data exchanges are resolved by the adapter layer. The adapter layer uses native ESB functions and custom code to translate all inbound messages into a standard NIEM compliant Simple Object Access Protocol (SOAP) call to the ESB. The team expects that over time source and target systems will develop the ability to initiate SOAP calls, resulting in deprecation of the adapter layer. Common data transport. As the state moves toward a real time web servicesbased exchange model, the need to move large data files to be processed in a traditional batch processing model diminishes. While this is an NC DHHS goal, NC FAST acknowledges that file transfers for batch processing will always be a reality in the IT landscape. To support these types of transfers within the ESB framework, NC FAST purchased IBM File Transfer Edition (FTE). This product provides a common platform that supports a variety of file transfer protocols such as SFTP, FTP, Connect: Direct, etc., while also supporting a native FTE transfer 6

7 mechanism based on the MQ Series platform. Using this tool drives the department toward standardization of products and processes with the complementary benefit of reducing the cost of ownership of maintaining a large number of products. Cost savings. Because the first NC FAST project was only recently implemented in all 100 counties, financial savings for NC FAST will be more accurately measured over the next year during the Operations and Maintenance phase. Financial savings realized by NC DHHS and the NC FAST Program will be commensurate with the realization of the following factors when the as-is and to-be states are compared. A reduction in software products will result in a reduction in costs, as does a reduction in the number of man hours needed to develop the code associated with a particular exchange. o Reduction in overall development effort and times. The reduction in effort to develop new exchanges and modify and maintain existing exchanges results in an overall cost reduction for these activities. The first NC FAST project, which provides case management and eligibility determination for the Food and Nutrition Services program, illustrates this. Using the GCF, 3 ESB developers implemented 16 services or exchanges containing a total of 36 business operations over approximately 1 year. 2 of the 3 developers moved to the Operations and Maintenance team and now provide Help Desk Tier 1 technical support for the exchanges. This is a stark difference from the support model used for traditionally siloed programs with individual point-topoint interfaces. o Common data transport. Using a common set of tools to move data from system to system and a general move to real-time web service calls will result in a reduction in the costs associated with the software products used for this purpose in the past. Other areas of savings. o The Configuration not Development principle results in the need for a different skill set to implement the exchanges. A senior developer with extensive JAVA experience is no longer needed to create an exchange where a more junior resource with configuration experience will suffice. o Applying the Standardized Framework means Generalized Troubleshooting principle to Operations and Maintenance staffing results in a broader base of potential resources that can troubleshoot a broader base of exchanges, resulting in lower operational costs. No longer are resources from each program area required for Help Desk Tier 1 support. More generalized resources who understand the GCF can support exchanges from multiple business units. 7