In addition to the inter-agency interoperability initiatives, intra-agency initiatives for interoperability exist between three main business unit divisions within OKDHS. These include Oklahoma Child Support Services (OCSS), Adult and Family Services (AFS) and Child Welfare Services (CWS). Currently OSDH is working independently on one interoperability plan, while OHCA is working on another interoperability plan and now OKDHS, partnering with the Office of Management and Enterprise Services (OMES), is developing a third interoperability plan. These separate efforts are creating disjoined plans and possible inefficiencies.

The intent is to come up with a unified overall interoperability plan that can improve data exchange processes, increase data quality and reusability, reduce errors and enhance data integrity between all the agencies.

The purpose of this SOA Roadmap is to provide OKDHS and its collaborating agencies with guidance regarding typical activities and initiatives that need to be executed as part of the SOA journey. This SOA roadmap will continually be updated as decisions are made and details are further defined. This project will provide opportunities for inter-agency collaboration and allow multiple State agencies to leverage SOA services and capabilities, in support of the state’s effort to meet the timelines of the Affordable Care Act (ACA) for citizen enrollment. 1.1.1 Goals/Objectives The major goals/objectives to be achieved with the implementation of the TO-BE system are summarized in Table 1.

Table 2: Project Outcomes Index Project Outcomes O1 This project provides opportunities for intra-agency and inter-agency collaboration. It allows OKDHS and multiple State agencies to leverage SOA services and capabilities, in support of the state’s effort to meet the timelines of the ACA for citizen enrollment. Leveraging SOA will provide for reusability and better data exchange to improve outcomes for vulnerable children and improve service delivery for clients. O2 The interoperability plan and SOA roadmap will outline compliance with the Seven Conditions and Standards as outlined by Centers for Medicare and Medicaid Services (CMS) and CMS Guidance for Exchange and Medicaid Information Technology (IT) Systems Version 2.0.

O3 Performance improvements can be realized through the development of business processes, enabled by SOA, which can automatically perform eligibility validation and cross-referencing, as web services are enabled across the enterprise. Through the SOA roadmap, the development of business processes and the validation of web services to support these processes can transform administrative activities to reduce redundancy of effort and streamline workflows to improve efficiency.

O4 Develop a roadmap for integration of SOA/ESB to allow fully automated data exchange and service reusability for all services exchanged between OKDHS and OHCA and other initiatives. 1.2 Assumptions and Constraints Assumptions and constraints that influenced preparation of this document include: • Schedule Constraints: Delayed start on Interoperability Planning Grant, scheduled contingent upon approval of SOA Roadmap. • Data Constraints: To narrow and manage the project scope, the initial focus is on Eligibility and Enterprise Master Person Index (eMPI), and data exchanges between agencies and/or programs.

• Hardware Constraints: Any required hardware must fit with SOA and Enterprise Architecture and acquisition of any additional hardware is dependent on funding or financial constraints. • Software Constraints: Any required developed or Commercial off The Shelf (COTS) software must fit within the approved SOA and Enterprise Architecture, and acquisition of any additional software is dependent on funding or financial constraint. • Organizational Constraints: Resource acquisition and allocation may be a factor in implementing the Interoperability Plan. Policies and procedures may be too specific to share or reuse for purposes other than eligibility.

• Security Constraints: Security mandates must be followed regarding the handling of Internal Revenue Service (IRS), Health Insurance Portability and Accountability Act (HIPAA), Social Security Administration (SSA) and any federal tax information.

In a sense, this barrier makes it difficult for certain organizations to “break out” of their current silos; although the Memorandum of Agreements (MOA) and Service Level Agreements (SLA) between organizations attempt to solve some of these issues, this barrier is ever present based on the pure mechanics. As implementation of the NHSIA Business Viewpoint strives interoperability through a functional point of view so must go the federal funding streams and associated restrictions and regulations if true interoperability is to be archived.

1.3 Benefit to Other States This Interoperability Plan may be used by other states to implement Enterprise Interoperability measures. 1.4 Breadth The focus of this interoperability effort will include: state and federal programs that require eligibility determination: Supplemental Nutrition Assistance Program (SNAP), Temporary Assistance to Needy Families (TANF), Low Income Home Energy Assistance Program (LIHEAP), Aid to the Aged, Blind and Disabled, and the child care subsidy. Other human services programs that will benefit from a new configuration of IT services include CWS, OCSS, Aging Services Division (Medicaid funded long term care waiver) and Developmental Disabilities Services (Medicaid funded community based waivers).

Other state agencies that are participating in the consortium include OHCA, Oklahoma Department of Mental Health and Substance Abuse Services and OSDH’s program; Women, Infants and Children (WIC). Other business segments involved in planning include the Department of Public Safety and the State Department of Education.

1.5 Human Services Program and Initiatives OKDHS is undertaking a multi-year, multi-program, agency-wide effort to update its technology, streamline and improve its business practices, consolidate its information systems, and provide a secure, compliant Web portal for OKDHS employees, clients and providers to conduct daily business…anytime, anywhere. OKDHS is pursuing a new Enterprise Software solution that is flexible and supports interoperability to allow internal and external stakeholder’s access to the Enterprise System and data, regardless of technology. OKDHS is seeking an Enterprise Software solution that will increase client use of self-service tools.

The project will lead to a fully-functional, automated system that meets federal certification, compliance and mandates for child support, child welfare, and adult and family services and the associated titles and certifications needed for certification.

Many aspects of the OHCA plan are consistent with the approach envisioned by the model. OHCA and OKDHS are working together on both of their initiatives to assure no duplication in funding or resources for similar projects using the MITA and NHSIA principles of re-usability. The proposed system will modernize existing system functionality to provide recipients a “golden standard” of customer care (i.e., a consistent look and feel across stakeholders and seamless customer service with consistent metrics to measure and continuously approve the customer experience). The proposed system will also significantly enhance the ability for providers to have prompt access to member eligibility and enrollment information to ensure that eligible individuals receive the health care benefits to which they are entitled and that providers are reimbursed promptly and efficiently.

An individual seeking health coverage in 2014 will be able to access information and assistance, and apply for health coverage, through multiple channels. All of these channels will connect with a standardized, web-based system to evaluate the individual’s eligibility for coverage through one of four programs: • Qualified health plans through the Exchange (with or without Guidance for Exchange and Medicaid Information Technology (IT) Systems 4 Version 2.0 May, 2011/Centers for Medicare & Medicaid Services advance premium tax credits and cost-sharing reductions) • Medicaid • Children’s Health Insurance Program (CHIP) • Basic Health Program, if established by the state MITA ensures the availability of high-quality health care coverage to families and individuals are achieved through a collaborative partnership between and within federal agencies and states responsible for implementation of the Exchanges and the ACA’s Medicaid and CHIP provisions.

MITA envisions a streamlined, secure, and interactive customer experience that will maximize automation and real-time adjudication while protecting privacy and personally identifiable information. Individuals will answer a defined and limited set of questions to begin the process, supported by navigation tools and windows that open to provide or seek additional information based on individual preferences or answers. The application will allow an individual to accept or decline screening for financial assistance, and tailor the rest of the eligibility and enrollment process accordingly. The required verifications that will be necessary to validate the accuracy of information supplied by applicants will be managed in a standardized fashion, supported by a

Individuals will attest to the accuracy of the information they supply. The goal of MITA is to serve a high proportion of individuals seeking health coverage and financial support through this automated process.

1.7 Health Intersection Currently Oklahoma has elected to not participate in the Federal Health Insurance Exchange (HIE), nor have an Exchange. However, the OHCA will coordinate with the Federal Exchange in a yet to be determined process by conducting their own intake process and determining eligibility. Additional Interoperability between NHSIA and MITA Programs for Oklahoma can be reviewed with Appendix A. Plans are to support a future exchange interoperability concept. OSDH is seeking a comprehensive solution for an Interoperable Public Health Information System (IPHIS), to prepare for participating with health information exchange activities and to improve the quality of data available to support decisions about improving the health of Oklahomans.

1.8 End Result Interoperability is the expected end result. Implementation of SOA/ESB under a NHSIA/MITA/NIEM framework guidance is the expected vehicle to achieve interoperability. An eMPI is also an expected end result. 1.9 Background/Overview SOA has emerged as a crucial enabling technology for interoperability among disparate pieces of software regardless of the network architecture, platform, or programming language. SOA is a conceptual framework for designing and building networks and Web services that allow for data to be exchanged where and when it is needed. SOA is a client/server design approach in which an application consists of software services and software service consumers (also known as clients or service requesters).

SOA differs from the more general client/server model in its definitive emphasis on loose coupling between software components, and in its use of separately standing interfaces (Gartner). SOA raises the bar in terms of quality in service offerings. Services

SOA is accomplished through two fundamental principles: interface abstraction and modularization. There are five criteria for an SOA application: modular, distributed, discoverable, swappable, and shareable. From SEI – Carnegie Mellon 1.9.1 Service-Oriented Architecture and Service-Oriented Systems SOA is a way of designing, developing, deploying, and managing systems, in which services provide reusable business functionality via well-defined interfaces. There is a clear separation between service interface and service implementation. Service consumers are built using functionality from available services.

An SOA infrastructure enables discovery, composition, and invocation of services. Protocols are predominantly, but not exclusively, message-based document exchanges. From a more technical point of view, SOA is an architectural style or design paradigm; it is neither system architecture nor a complete system. Systems that are built based on the SOA characteristics listed above are called service-oriented systems. 1.9.2 Services Services are reusable components that represent business or operational tasks, such as customer lookup, credit card validation, weather lookup, or line-of-sight calculation.

Reusable is a key element of this definition because it is what enables the creation of new business and operational processes based on these services. Services expose their capabilities via well-defined, standard service interfaces. In a service-oriented environment, service interface definitions are available in some form of service registry. If systems are built as components, then each system can be developed and maintained independently. SOA is a set of design patterns that guide the building and integration of these mini-application pieces.

1.9.3 Exploration Questions/Answers This plan in conjunction with the plans covered under this grant will seek to explore and answer the following questions in Table 3: Table 3: Exploration Questions/Answers Index Questions/Answers Q1 What resources will be needed to integrate OKDHS human services programs into MITA Maturity Model (MITA Framework Version 3.0)/ NHSIA compliant architecture?

It will depend on the level of adoption. Resources may include architects, business process engineers, developers, and most importantly executive leadership to provide organizational commitment.

Q2 What technical and business architecture will be needed at OKDHS to integrate MITA? What is the security architecture that protects the interests of all State agencies? A2 SOA and ESB architectures will be needed. Identity management and access control is needed including strong authentication. Network and infrastructure security also make up the security architecture. The Global Federated Identity and Privilege Management (GFIPM) could be used for federated identity and privilege management to allow users from one federation partner to seamlessly access resources from another partner in a secure and trustworthy manner.

Q3 What is needed among the health and human services agencies to develop and share eMPI?

A3 This is under review although it is known that coordination and collaboration is needed. Research is underway to determine the extent of current level of effort already done by OHCA and OSDH in planning to share eMPI services. Expectations are that sharing software, licensing and expertise will provide longer term cost benefits. The participating agencies were questioned as to the matching criteria that they use in their systems to identify a person. Except OSDH, all other agencies thought the idea of applying Master Data Management (MDM) technology would be a valuable approach when focusing on eMPI for interoperability.

Leveraging the eMPI concept by utilizing MDM and storing in a master data for ease of access and sharing would reduce errors, maintenance and cost of the stored data. OSDH has a state mandate that Birth information is only released to certain designated agencies and their data cannot be shared for eMPI purposes.

Q4 What initiatives of the MOSAIC human services eligibility and case management system can be shared with OHCA initiatives under the ACA? A4 MOSAIC initially focused on the three largest business divisions of OKDHS. MOSAIC is currently being considered at an enterprise level. Initiatives of the proposed MOSAIC system will be reviewed to determine which can be shared with OHCA for ACA efforts. Q5 What efficiencies can be gained by using SOA? A5 Sharing and agility are the major values of SOA which provide efficiencies. Sharing provides leverage and reuse. Agility provides the capability to change more rapidly.

SOA helps with silos by creating interoperability agreements that reconcile how systems talk to each other, the data formats they use, and the organizational barriers to cooperation.

Q6 How can governance be used to achieve the wide range of performance expectations? A6 Governance is critical. SOA governance is a combination of best practices to help combat sprawl. Through governance, service-level agreements can be established to define performance expectations as well as measurements that confirm that services are performing as expected. Q7 How can Oklahoma improve overall State IT operating and cost efficiencies? A7 Increasing interoperability and developing reusable, standardized services will drive

Adoption of NHSIA, MITA, NIEM, SOA and ESB implementations will assist in this effort. 1.9.4 Options Considered As part of the SOA Roadmap development, several different Enterprise Architecture (EA) frameworks and methodologies were reviewed. The Zachman Framework, The Open Group Architecture Framework (TOGAF), Federal Enterprise Architecture (FEA) and Department of Defense (DoD) Architectural Framework (DoDAF) were reviewed. SOA Methodologies and SOA Maturity Models were also reviewed to determine potential usefulness and appropriateness for adoption by Oklahoma. SOA maturity models from Microsoft, IBM, Oracle and The Open Group Service Integration Maturity Model (OSIMM) Version 2 have been reviewed.

These maturity models provide a framework and a roadmap much like MITA does.

The NHSIA developed by the Administration for Children and Families (ACF) is a framework to support integrated eligibility determination and information sharing across programs and agencies. NHSIA focuses on enabling information exchange and sharing IT services among information systems. Oklahoma has chosen to adopt NHSIA and MITA as standards for requirements with the partnership being established for Interoperability. In the event NHSIA does not address a process, MITA will be used. 1.9.5 Options Impact and Goals 1.9.5.1 Improve service delivery for clients The implementation of SOA across state agencies will benefit the client in several ways by: • Reducing the amount of documentation families must submit to apply for multiple benefits.

• Reducing the time spent by families applying or retaining eligibility. • Providing accurate, reusable and easily accessible services. • Reducing errors by increasing efficiency and improving performance. • Reducing customer dissatisfaction by supplying readily available information. The eligibility determination is currently a mix of processes; there are manual and electronic processes for the various federal social service programs that are integrated only through custom interfaces with no exchange standards. No standard electronic application currently exists that can be used across multiple public assistance programs.

An interoperable, reusable eligibility system will help bridge this gap. This improvement can be enabled by not only leveraging the evolving Oklahoma enterprise SOA framework, but also the governance strategy to facilitate proper design and execution of a prospective enterprise workflow. This use case also provides an

Oklahoma does not currently have a statewide eMPI; the addition of an eMPI will aid all agencies data steward functions when attempting to align persons across systems. For example, currently, multiple identifiers exist for eligibility determination for, the Insure Oklahoma (IO) members, including a member ID (an OKDHS identifier) and an IO case ID (an Insure Oklahoma identifier). In the current workflow where manual reference checks are performed, the opportunity for errors increases. Through the development of a statewide eMPI: • Errors can be reduced • Accuracy of eligibility determinations increased.

Information reported to or available in one program can be shared with other programs in support of program integrity efforts.

1.9.5.3 Improve Administrative Efficiency Addressed across the Interoperability Plan tiers, performance improvements can be realized through the development of business processes, enabled by SOA, which can automatically perform eligibility validation and cross-referencing, as web services are enabled across the enterprise. Through the SOA Roadmap, the development of business processes and the validation performed by web services to support these processes, administrative activities can be transformed to reduce redundancy of effort and streamline workflows.

2 ARCHITECTURE FRAMEWORKS The scope of this interoperability exploration and planning effort includes developing a roadmap for integration of SOA and ESB to allow interoperability, fully automated data exchange and service reusability for all services exchanged between OKDHS, OHCA, OSDH and other initiatives.

In addition to the inter-agency interoperability initiatives, intra-agency initiatives for interoperability exist between three main business unit divisions within OKDHS. These include OCSS, AFS and CWS.

OKDHS hopes to embrace SOA as a business-IT strategy. The development of a roadmap for implementing SOA to provide better alignment between business and IT is an effort to improve interoperability. As previously stated, several architecture

2.1 Building a(n) SOA Roadmap Typically, all roadmap building follows the same four steps: • Where are we now? (current state or AS-IS) • Where do we want to be? (desired future state or TO-BE) • What is the gap between the two? (gap analysis) • What is the path to get to where we want to be? (roadmap to TO-BE) The approach used in this roadmap is to identify the current state or AS-IS architecture and identify the future SOA state or TO-BE architecture and analyze the gaps between the two. This will provide a clear understanding of where we are and where we want to be.

The approach that NHSIA takes is to architect a core set of essential capabilities that everyone needs. The core capabilities enable critical information sharing and create an environment that allows new capabilities to evolve more easily. The core NHSIA capabilities: • Provide a foundation for interoperability • Provide foundational capabilities or information SOA ESB NHSIA Figure 1: Identify AS-IS and TO-BE

Initial work on NHSIA addressed the business areas covering client management, eligibility and enrollment, provider management, service management, and performance management in some detail. Other business areas including business relationships, program management, operations management, financial management and contractor management defined at a high level. The core elements provide functionality upon which end-user capabilities can be built. Implementing NHSIA core concepts means that these core information system elements will be available: • A SOA infrastructure which provides the foundation for IT service discovery and re-use.

• A set of hubs to share IT services. Information sharing should use NIEM-based standards. The initial shared IT services and information sets are those required to support core capabilities. • For authorized users, single sign-on and attribute-based access control to streamline the user’s experience and abide by confidentiality agreements. • A set of repositories to facilitate selected data aggregation and analysis. In order to define the NHSIA framework we have to review and attain a clear understanding of NHSIA. Many aspects of the approach outlined in NHSIA are based on methodologies recommended in the Global Reference Architecture (GRA) that has been published by the Department of Justice.

NHSIA takes the MITA concepts and principles and extends them beyond Medicaid to apply to human services.

Therefore, an understanding of GRA and MITA would be helpful. The approach taken in developing this roadmap will include the following steps: • Review NHSIA • Define NHSIA Framework as it applies to Oklahoma • Analyze AS-IS Environment • Define NHSIA Capabilities • Define SOA Reference Architecture • Define TO-BE Architecture A thorough review of NHSIA is underway. Additional NHSIA information will be detailed in section 5.1 TO-BE System.

Systems involved in the Interoperability project are OSDH, OHCA, CWS, OCSS, and AFS. These systems have various types of data that are being exchanged via interfaces. Interfaces could be Real-Time (data is accessed directly any day/anytime), Transactional or Transfer (push/pull via ftp services). 2.2 National Human Services Interoperability Architecture (NHSIA) NHSIA proposes an architecture framework to facilitate information sharing, improve service delivery, prevent fraud, and provide better outcomes for children and families. NHSIA is enterprise architecture, the enterprise being the provisioning of human services across the nation.

This national enterprise is large, and comprises many lower level enterprises. Therefore, NHSIA can be thought of as a multi-enterprise or community architecture.

NHSIA is part of a rough hierarchical set of related architectures as illustrated in Figure 3. The scope, level of detail, and content of these architectures often do not dovetail in a simple, structured way. Nevertheless, NHSIA should be developed with an understanding of these related architectures to ensure interoperability and avoid duplication. The architectures are federated; each level has a scope and purpose and is defined to an appropriate level-of-detail as summarized in Figure 3.

Each viewpoint serves the needs of a specific user or group, such as an executive manager making investment decisions, an operational user of the systems, or a systems developer designing data structures, services, and applications. The DoDAF has evolved over a decade to include multiple viewpoints. NHSIA has adapted DoDAF to include the viewpoints shown in Figure 4. The adaptations include merging the DoDAF Systems and Services Viewpoints into a single Systems Viewpoint and pulling out an Infrastructure Viewpoint as a separate item from the Systems Viewpoint.

Includes a NHSIA scoredcard and performance reference model. Business Business processes and operational scenarios Systems Describes new and legacy system components in the layers of the to-be architecture including software applications and services: their context, components, functions, and interfaces.

Infrastructure The IT environment including networks, computing facilities, servers, and enterprise services Project Strategies and projects planned or required to implement the capabilities defined by the architecture

MITA provides a common framework in the Medicaid arena to focus on opportunities to build common and shared services by decoupling legacy systems and processes and breaking down silos. Table 4 shows how NHSIA and MITA are closely aligned. Table 4: NHSIA and MITA Comparison NHSIA makes extensive use of the MITA Business Architecture and uses it as the basis for the NHSIA Business Viewpoint.

NHSIA provides a framework for shared business processes and understanding processes common across programs. This will help identify capabilities and processes that can be shared or reused across programs.

It is also possible to share the underlying infrastructure across human services programs. Technologies such as SOA make it possible to share the underlying hardware, network and systems software across multiple human services programs as depicted in Figure 7.

Outreach, governance, and architecture maintenance will be longer-term federal activities. The roadmap shows state governments starting with planning, design, and prototypes/pilots, and then shifting to full-scale NHSIA implementation. The initial planning, design, and prototypes/pilots might include establishing core infrastructure, shared IT services, hubs, and initial end-user capabilities. Development of NIEM-based standards for information exchange is likely to be a longer-term activity. The funding and acquisition of the NHSIA components may take many forms. There is no single acquisition approach for all of NHSIA implementation.

2.4 Implementing NHSIA The steps recommended for the State to follow for implementing NHSIA: • Assess Current Situation • Plan and Design • Support NIEM Standards Development • Conduct NHSIA Prototypes and Pilots • Update Plan and Design • Implement NHSIA Incrementally See Figure 9 for steps recommended by NHSIA.

It is a major client services system. Family Assistance and Client Services (FACS) is the Graphical User Interface (GUI) “front end” to the PS2 System. • CWS – KIDS is a Statewide Automated Child Welfare Information Systems (SACWIS). SACWIS is a comprehensive automated case management tool that supports social workers in foster care and adoptions case management. • OHCA – MMIS is a highly sophisticated, feature–rich system centered on a strong, Medicaid–specific relational data model.

• OSDH – Public Health Oklahoma Client Information System (PHOCIS) supports client services. The AS-IS detailed overview for the systems identified above can be found in Appendix C. 4 GOVERNANCE To achieve interoperability for this and other cross-agency activities, a governance model for a SOA must be put in place to guide sharing at both the data and web services levels, and achieve a cross-organizational consensus and understanding at the workflow (i.e., business process) level. This project will codify and execute infrastructure/data governance, web service governance, and business process governance models to meet the needs of the enterprise.

To accomplish this, governance requires organizational structure and processes and must identify who has authority to define and carry out its mandates. It must address the following questions: • What decisions must be made to ensure effective management and use? • Who should make these decisions?

• How will these decisions be made and monitored? • How will these decisions be communicated? The intent is to achieve goals, add value, and reduce risk. The distinction with SOA governance is what things need to be governed when SOA is applied to our application portfolios. What are the extra things that have to be covered? SOA governance has to be in alignment with the rest of the governance in the organization including IT and Business governance.

• Membership. The board is composed of 13 members appointed by the OKDHS chief officers are as follows: 1. Chief administrative officer – two members 2. General counsel – one member 3. Chief financial officer – one member 4. Chief information officer – one member 5. Chief coordinating officer – four members 6. Chief operating officer – three members 7. Chief information officer • Bylaws. The IT Governance Board adopts, alters, or amends bylaws that must be ratified by the Director and Chief Officers.

4.1.2 OHCA – IT Governance Model OHCA currently chairs group meetings of a statewide HIE group to develop a state government exchange mechanism.

This group consists of state health and human services agencies, including: OKDHS, OSDH, Oklahoma Department of Corrections, Oklahoma State Department of Mental Health and Substance Abuse, Vocational Rehabilitation, and Department of Insurance. In the future all of these entities will be involved in the statewide HIE governance committee. OHCA is in the process of establishing an EA program. OHCA's current infrastructure has evolved over time without an EA program in place to guide design decisions or enforce standards. Some of the results of not having an EA program in place include tightly integrated monolithic systems, stop-gap business processes, redundant technologies and data fragmentation.

The establishment of an EA program will begin the process of translating business vision and strategy into effective information technology services. The intent of the EA program is to provide direction and regulation of projects to ensure the reliability, interoperability and sustainability of systems used by OHCA. The value of the EA is realized through the creation and compliance with standards and guidelines.

Compliance with MITA will also facilitate the faster delivery of systems solutions and consistent planning and implementation across the enterprise.

4.1.3 OSDH – IT Governance Model The OSDH IT Steering Committee Charter establishes the change control process for programs supported by the OSDH IT Infrastructure and Software Development Teams. The scope of the OSDH IT Steering Committee is to review, prioritize and make recommendations on all IT infrastructure and development projects within OSDH. The OSDH IT Steering Committee is responsible for the coordination of Infrastructure and Development project requests and their tracking process. Some duties of the IT Steering Committee will include, but are not limited to: • Annual Review of the IT Budget • Review of Short-Term and Long-Term Equipment Replacement Plans • Project Funding Impacts • Outsourcing Recommendations • Advise Senior Leadership on project developments that impact project scheduling and other programs within the OSDH 4.1.4 Overall Current Governance Structure Figure 12 depicts the current governance structure of the agencies and business units involved in the scope of the interoperability effort.

Figure 15: Oklahoma’s Enterprise IT Governance Model 5 TO-BE SOA STRATEGY 5.1 TO-BE System Overview The desired or TO-BE state is to have an environment characterized by interoperability. Interoperable systems share information and processes to efficiently deliver integrated services to the client community. Interoperability can be achieved via the design and implementation of an overall NHSIA Architecture, which defines the principles, standards, services, security, and interfaces to be followed by the component elements within the total system of systems. Figure 16 illustrates the potential TO-BE System.

The overall SOA Strategy will be derived from three strategic areas listed in the following steps: • Step 1: Define the SOA Reference Architecture • Step 2: Define the SOA Roadmap • Step 3: Define the SOA Governance Strategy Together these define the SOA Strategy.

Although we define the SOA strategy in three steps, the suggested best approach is to run these steps in parallel or in an iterative fashion, feeding off each-other. For example, scoping the SOA initiative is part of the roadmap but should be the first activity, as it influences everything else. The roadmap should be driven in large part by the SOA reference architecture but should also consider the implementation of the governance strategy.

5.1.1 Step 1: Define the SOA Reference Architecture The SOA reference architecture is, among the three components of the strategy, probably the easiest to define and most widely documented. Easiest because in IT we

In fact, most SOA initiatives – even the most technically and least strategically focused – probably have SOA reference architecture of one form of another.

Initially only general guidelines are included describing what we believe should be contained in the SOA reference architecture. This will evolve and become more defined as we work through the other interoperability project deliverables (web services, business processes, NEIM analysis, and eligibility workflow.) Figure 17: SOA Reference Architecture This SOA Reference Architecture, as seen in Figure 17 is comprised of nine layers as follows: • Operational Systems Layer: Programs and data of the operational systems of the enterprise. The new and existing infrastructure is needed to support the SOA solution.

• Service Components Layer: Software components, each of which provides the implementation or “realization “ for a service, or operation on a service, and binds the service contract to the implementation of the service in the operational systems layer.

• Business Processes Layer: Business processes and compositions in which business processes are composed of other business processes and of services. • Consumer Interfaces Layer: The programs by which the users interface to the services.

• Integration Layer: Integration of and communication between other building blocks, including messaging, message transformation, complex event processing, service composition, and service discovery. • Quality of Service Layer: Monitoring and management of the quality of service of the architected system, including its performance, reliability, availability, scalability, security, and manageability. • Information Layer: Management, analysis, interpretation, and transformation of data. • Governance Layer: Governance rules and procedures. Services and programs that support the application of the rules and the operation of the procedures.

People may also interact directly with other people to access HS information and services.

Examples of components in the access layer include browsers, web portals, web sites, interactive forms, kiosks, telephone, voice mail, etc. • Applications Layer: The applications layer includes high-level applications that normally support multiple human services domains, agencies, and programs. In this context an “application” is application software - a computer program designed for end users to accomplish specific tasks. What constitutes a “domain” depends on how the jurisdiction organizes its services.

Examples of components in the applications layer include human service applications that support multiple domains: eligibility determination, case management, and others.

This layer also includes program management applications that support multiple programs: partner management, performance monitoring, and others. This layer may include applications unique to a domain, agency, or program (to meet unique requirements or because they are legacy applications). This layer may also include integrated applications (e.g., one application that handles eligibility determination and enrollment) to support multiple activities in one or more domains, agencies or programs. Finally, this layer includes supporting applications such as rules engines, workflow systems, document management systems, and analytics packages.

Applications should be interoperable so that users can easily accomplish all their tasks seamlessly.

• Shared Services: The shared services layer includes components that deliver functionally-oriented IT services and information (application services and data services) that are unique to the human services domains. Examples of shared services include updating information about a person or verifying credentials for a service provider. The information and information structures shared by multiple applications (e.g., master person index) also appear in this layer. “Wrappers” to enable legacy systems to discover and use shared services are in the shared services layer.

Elements in this layer include the commercial off-the-shelf IT services, hardware, and software that support all the upper layers.

Examples of components in the infrastructure layer include adapters, application servers, and data integration servers:  SOA  ESB  Cloud Computing  Infrastructure Security • Business Rules Engine: Business rules engine is another component typically employed as a part of, or in conjunction with an ESB. A business rules engine is a software system that executes one or more business rules in a runtime environment. These rules will come from legal regulations, organizational policy, or other sources. A business rules engine enables such rules to be defined, tested, executed and maintained separately from application code.

This provides a mechanism to adapt to changing rues without the need for major system updates.

A business rules engine typically includes a repository that permits rules to be externalized from application software. Most also include a rule definition tool that allows business experts to define and manage decision logic that was previously buried in software. • Services Registry: A services registry is one of the fundamental pieces of SOA for achieving reuse. Typically a component of the ESB, it is a place in which service providers can document information about their offered services and potential service consumers can search for services. The reuse of services greatly depends on the ability to describe and publish the offered functionality of the services to potential consumers.

A service registry organizes information about services and provides facilities to publish and discover services. • Architecture Drivers: These architectural drivers influenced the development of the systems reference model and the identification of proposed applications and shared services. Architectural drivers are externally imposed authoritative mandates, policies, or conditions that strongly influence the development of NHSIA. These include:

It should not include every detailed step for the length of the roadmap as it would be very time consuming to define and in all likelihood it would be wrong the minute you start the implementation. Instead, pragmatism should guide you here: the roadmap should be very clearly defined for the first few months and more and more open the further in time it gets.

As with all the elements of SOA strategy, the roadmap should also be a living document that is refined and updated as you go along, but which helps you make sure you don't miss any important steps. Ideally you should represent the roadmap graphically to ease communication to, and achieving buy-in from key stakeholders, including IT management. Short Term For the first few months, the roadmap should include the one or two projects that you have chosen to first implement SOA, or if SOA has already been used, where you will first apply your new SOA strategy. It should also define to what extent the governance strategy and the reference architecture will be implemented – remember to be pragmatic: focus on the easiest parts that will bring you the most benefits.

You may also want to include one or two of the riskiest aspects of the strategy so that they can be tried out and de-risked.

Mid to Long Term Longer term, the roadmap should specify when and in which order all the aspects of the strategy should be implemented.

It helps however to estimate a date for when this trigger should be reached.

It might also include when the platform or the SOA is rolled out to different business units or agencies for adoption. SOA Objectives Ideally you should also include in the roadmap when you expect to reach certain target objectives of your SOA. For example if one of your objective is "reduce partner on- boarding time", you should specify when it would be reduced by say 20%, 40% and 60%, based on how the key systems that are integrated with partners are SOA-enabled. 5.1.3 Step 3: Define the Governance Strategy An important part of the strategy describes how you will govern your SOA. Without governance, you will likely not follow your SOA reference architecture, your SOA roadmap will falter and ultimately you will not achieve your SOA objectives.

A governance model for SOA must be put in place to achieve true interoperability. Governance is about providing guidance for decision-making. Governance defines the principles for making decisions when executing SOA. Some type of SOA Governance Council must be established to guide sharing at both the data and web services levels, and achieve a cross-organizational consensus and understanding at the workflow or business process level.

Since SOA is a highly shared environment, it is critical that the SOA governance model be defined and implemented to manage an environment that is acceptable to all stakeholders. Standards must be set and policies determined for how services will be created, certified, modified, and retired as well as how security will be defined and enforced. Initial and sustaining funding models and the mechanisms to implement SOA infrastructure must be agreed upon. Figure 19 is a high-level view of how SOA governance extends and supports both enterprise architecture and IT governance.

Failure to address organizational and change management issues will lead to slow SOA adoption that lacks coherence, because employees aren’t empowered (through organizational structure, training, and incentives) and aren’t held accountable for delivering on SOA benefits.

An interagency governance team must work together to create rules for quality data being exchanged and accountability between agency’s hosting and exchanging data. The philosophy and level of data governance must be agreed upon by the interagency team to ensure valid, current and secure data. The data must be shared using a national common format as NIEM. The governance of data must meet Federal and state policy regulations. Some of the typical SOA governance decisions to be made in each SOA initiative are: • Which Services are needed?

• Which Services shall be implemented first? • Is this really a new, reusable service? • Who pays for the development and maintenance of the service? • Who owns this Service? • Who approves changes to existing services? • How do proposed and approved changes to existing services impact its current consumers?

If there is no governance established for activities that address the enterprise as a whole, then the NHSIA program manager may establish a governance structure for NHSIA. Essential elements of a governance structure focused on NHSIA would include: • Executive Steering Committee (ESC): This should include the executives of the primary agencies that provide human services. This committee establishes top-level policies and priorities for the program and architecture. The ESC approves strategic plans and budgets.

• NHSIA Program Manager (PM): The NHSIA PM has the responsibility for planning and executing the program.

They are responsible for reviewing proposed changes to the architecture, recommending approval or rejection to the NHSIA PM, and ensuring that changes are properly incorporated into the architecture.

• Architecture Staff: The architecture staff supports the chief architect in developing and maintaining the architecture. • Policies and Procedures: A set of governance, compliance, and usage policies and procedures is necessary to define the roles and responsibilities of each of the NHSIA stakeholders. 5.2 TO-BE Security Requirements Securing open, loosely coupled systems in an SOA requires a much more sophisticated security approach than traditional distributed computing architectures, involving multiple administrators that support distributed users. Different systems now have different policies and possibly different security mechanisms.

As a result, administrators within the enterprise must manage security much more actively than was necessary in the closed, "islands of security" model. In addition, enterprises should centralize their administration capabilities, and implement a hierarchical, delegated administration model to maintain a coherent, yet scalable enterprise security policy. Likewise, when organizations seek to work together in a trust relationship, they must federate their enterprise identity management capabilities. Such federation can both take advantage of SOAs within the participating organizations, and also forms an essential prerequisite for extending SOAs beyond the edge of the enterprise.

Authentication proves that the requestor of the service is who they claim to be. The authentication service may be one that supports some type of identity management service.

Authorization determines the set of services the user is entitled to use. Typically, authorization will be based on several dimensions such as user’s role or type of user (employee, contractor, vendor, etc.). Access control determines which functions and data within a service the user is entitled to use. These will be a set of specialized services that allow a user access to specific functions, like the ability to edit, update, or delete given data or content. Privacy & Integrity within SOA security utilizes privacy (encryption-decryption) and integrity (signature-verification) for information in motion as well as information at rest.

Through Secure Sockets Layer (SSL) the transport layer is secured, whereas messages using Web Services (WS)-Security standards, Simple Object Access Protocol (SOAP) and Extensible Markup Language (XML) are encrypted and signed granularly at the content-level. The combination of transport-level and content-level privacy and integrity provides significant control for companies to implement their security policies. With such flexibility, the burden of testing possible variations in the standards used, as well as the content over which the privacy and integrity policies are implemented, is now the responsibility of the quality assurance and security team within the organization.

All new web applications, created after 4/1/2012, that require external users to log in must use the OKDHS Enterprise Portal for registering users, maintaining credentials, resetting passwords, requesting and receiving access to secured web applications. Typically users register themselves, and request access to applications. It is recommended for current web applications that use another login, to be converted to use Enterprise Login when it makes business sense to do so.

All web applications that require external users to log in must use the OKDHS Enterprise Single Sign On (SSO) when logging in to the application as defined in the documentation for Enterprise Login. This documentation is available in the OKDHS Application Documentation shared folder under Global Modules. Security for Internal Web Applications: All internal .NET applications will use Integrated Windows Authentication using the user’s OKDHS user ID and Active Directory security groups.

An application needing to authorize access to secured areas within the application must use Active Directory groups to do so. All internal .NET web applications needing to restrict access will use the Enterprise Security Module. The Enterprise Security Module (aka Global Security Module) provides ASP.NET Intranet applications with the ability to perform security access management. This module must be used by all internal OKDHS .NET web applications that have security requirements that include authentication and/or authorization. Any enhanced authorization requirements that cannot be provided by Enterprise Security Module must be developed with the approval of the Enterprise Architecture & Engineering Services (EAES) unit.

5.2.3 Security for Web Services and Windows Communication Foundation (WCF) Services Web services and WCF services that are not for public consumption must take precautions that prevent unauthorized applications from calling them. Any Web/WCF Service that is not meant for public consumption must have security to restrict access to authorized users and/or applications. The EAES unit will provide guidance on how to implement said security. Web/WCF services must live on an internal web server. If they need to be accessed from the outside, they must be accessed by a web application that lives in the DMZ.

If a need for a public-facing Web/WCF service arises, it must be discussed with and approved by the EAES unit. EAES will collaborate with the appropriate project team members to plan for how this should be done in a secure manner. SSL/Transport Layer Security (TLS) must be used on all web applications and web/WCF services that are transmitting secure data, whether internal or external. Any other Web/WCF service security methods must be approved by the EAES unit before use.

5.2.4 Security for Databases Web applications or web/WCF services that access databases have the responsibility to verify that the person accessing the data has the authority to do what they are asking to do. The database will be accessed by the application using a proxy ID after the application has verified the request is authorized. Databases that need to be accessed by web applications in the DMZ must live inside the OKDHS network and be accessed by an internal web or WCF service that is called

In addition to the web application determining if the user has access, the internal web/WCF service will perform its own security to make sure the application calling is authorized to call it. 5.2.5 Exceptions Exceptions to this standard must be approved by the EAES unit. Any dispute regarding an exception request should be escalated to a Data Services Division (DSD) Director. This standard applies to COTS products but exceptions for these will be evaluated on a case-by-case basis.

5.3 TO-BE SOA Interfaces User interfaces should be componentized. While it is permissible to have multiple types of user interfaces to interact with (i.e. multiple browser views customized for the users’ needs, Wireless Device Markup Language (WDML)/Wireless Markup Language (WML) views, e-mail, etc.), the common user interface barrier seen between applications should be eliminated. Every OKDHS worker should simply have a portal-like ability to see all the data they need to do their job without manually going to different websites or opening other applications. The fluidity should ultimately make it unknown to the user that the applications or the sources of data they are interacting with in the backend are different.

Similarly, interfaces for external OKDHS clients should be designed from the same perspective – whether they are web sites, kiosks, email based, or phone based Interactive Voice Response (IVR) systems, they should be accessing the same middleware components and be reusable. User Interfaces in the TO-BE system are somewhat dependent on the design of the services and how they plan to be implemented. Some of the current user interfaces might remain as they are right now, or may be modified and new ones might evolve. Choices that we make also depend on the technology that we will be using in the TO- BE System.

New technologies will impact the way the exchanges are handled. Using MDM to store master data will change the way the stakeholders handle the data exchange because it changes the process of exchange and service delivery. User interfaces might be impacted due to the way the exchanges will be handled. 5.3.1 SOA and the Enterprise Service Bus (ESB) There is no universal definition of Enterprise Service Bus. Vendors define the term differently according to their own market in such a way that they are the only vendor that has a product that meets their definition. The only similarity between all of the vendors’ ESB implementations is that at least part of it is based on Message Oriented Middleware.

OKDHS’ application architecture supports the concept of a messaging layer, but currently has no specific product that performs this function.

5.4 TO-BE Web Services OKDHS supports the use of web service standards. The use of basic web services standards gives the enterprise one of the best ways for multiple applications to reuse code. The nature of a basic web service is: • Has directed one-to-one bidirectional request/response connections • Has flow routing that is directed by the client (sender) in a “find-bind-invoke” fashion • Employs a linear path of execution through a hierarchy of modules • Is closed to new, unforeseen input once a flow is started There are three main areas for the use of web service technologies at OKDHS: 1.

As a communications mechanism for entities external to OKDHS’ network to interact with OKDHS applications 2. For making application components available for cross platform reuse within the enterprise 3. As a communications mechanism between different layers running within different containers.

Each of these three areas has different needs and goals that will affect the design. Web services are not a “one size fits all” with regard to design, use, and implementation. • As a communications mechanism for entities external to OKDHS’ network to interact with OKDHS - In this case, the use of the web service is viewed as a gateway to OKDHS so using the most popular standards are of the highest priority. The most popular standard, SOAP (over HTTP), was designed for this kind of use. The intent of these kinds of web services is that they are called infrequently (i.e. low volume of calls).

• For making application components available for cross platform reuse within the enterprise - SOAP is a heavyweight protocol.

It uses a large and complex XML envelope and is up to ten times slower than binary network protocols like RMI or IIOP. For this reason, it may not be the best standard for

Generally this kind of use of web services does not use standard protocols because of the overhead. Highly efficient code is more important than the standard in this case because the framework is generating the skeleton and stub code. The developer never directly interacts with the generated web services code directly.

6 RECOMMENDED APPROACH 6.1 The SOA Roadmap The SOA Roadmap is based on several reviewed SOA Methodologies, SOA Maturity Models and the current SOA Maturity within the state. Most agencies have little to no SOA. This SOA Roadmap indicates the typical SOA initiatives that need to be performed to increase the level of SOA maturity within the organization. The initiatives indicated are based on the Maturity Levels of the SOA Maturity Model, and the deliverables and focus areas indicated in the SOA Methodology.

6.1.1 Construct and Maintain Master Services Portfolio As part of implementing SOA, it is recommended that service portfolios or a Master Services Portfolio be established where all defined business and IT services can be tracked.

This service portfolio(s) will enable the reuse of services already designed, and further enhance standardization of services across the enterprise. Once these business and IT service repositories have been defined an applicable software development lifecycle (SDLC) should be updated to ensure that during the solution design and development phases the business analysts and developers query the service portfolio(s) to identify and reuse existing services if possible rather than unnecessarily duplicating functionality and services.

6.1.2 Implement Cross Enterprise Security As the institutionalization of SOA enabled business processes matures the management of security across these more agile business processes becomes a critical factor.

The establishment of cross enterprise security will enable the state to deploy agile business processes with more ease and in less time. The establishment of cross enterprise security will also reduce the amount of time and effort that needs to be spent on user account maintenance especially relating to the various enabling systems (often legacy) that users need access to when they are granted access to a business process. Cross enterprise security allows the organization to make the concept of “single sign on” a reality.

6.1.3 Extend the Scope of SOA Solutions to Span Multiple Business Units Start simple then increase complexity as SOA efforts mature. As SOA maturity increases and SOA capabilities are established the state should engage in more complex SOA projects spanning multiple integrated applications across multiple business units. It is important to ultimately engage in the more complex projects as they typically involve complex business processes that can deliver considerable benefit to the organization when supported by SOA principles and architecture resulting in agile business processes.

6.1.4 Extend the Scope of SOA Solutions to External Business Partners Several of the agencies’ business processes span both the agency and their business partners.

Once the SOA maturity has reached a level where substantial benefit has been realized from the institutionalization of SOA internally to the organization, it is recommended that the agency extend the scope of the SOA initiatives to include business processes spanning both the agency and their external business partners. An obvious prerequisite for this expansion is that their business partner(s) needs to be able to provide the required technical and business services to enable the multi-organizational business processes.

6.1.5 SOA Communication and Update of Applicable Knowledge Portal In order to ensure that the Business and IT stakeholders of the organization are aligned in terms of the goals and objectives of the SOA program, it is critical that an Enterprise SOA Strategy be formulated and agreed by the business and IT stakeholders involved. It should be noted that the required strategy is an enterprise strategy, and should span the strategic objectives for SOA across the entire enterprise, not only selected business units.

This will ensure that a common vision and mission for the SOA exists within the organization, and that no rumors regarding the SOA program derail the program. Further, the ongoing communication of SOA related initiatives and the progress towards higher levels of maturity is critical to the success of SOA adoption in the state. Knowledge portals or information sharing sites such as SharePoint sites or the InfoNet portal is an ideal mechanism for knowledge sharing, but should not be the only method of communicating with the rest of the business.

6.1.6 Develop Target Enterprise SOA Architecture A high level target Enterprise SOA Architecture should be developed based on a SOA Reference Architecture. This architecture should consist of the fundamental SOA components, these fundamental components typically includes the following: • Communication Backbone • Business Process Management Application(s) • Business Services Portfolio • Technical Services Portfolio • Business Rules Engine • Data Warehouse • Web Portal The target SOA architecture does not need to be a logical architecture of the entire SOA solution, a conceptual view of the SOA architecture is sufficient at this stage, provided that the conceptual architecture includes all the fundamental SOA components and indicates their interaction between the components on a conceptual level.

Added a new line here 6.1.7 Specify SOA Policies and Procedures In order to ensure the successful establishment of the SOA architecture, enterprise SOA policies and procedures need to be developed. These policies and procedures are required to guide and govern the design, development and deployment of SOA in the organization. One of the key enablers of a successful SOA architecture is the standardization of SOA components to encourage and enable reusability. Enterprise SOA policies and procedures are required to enhance the standardization of SOA components, and ensure that a common approach is used across the enterprise to realize the target SOA architecture.

6.1.8 Integrate SOA Principles into Organization Wide SDLC To ensure that the SOA program is delivered consistently across the state, it is important to amend the existing SDLC within the state to include SOA principles.

The SOA principles that need to be integrated into the existing SDLC should influence the design, develop and deploy phases of the existing SDLC, and should ensure that the revised SDLC is aligned to the enterprise wide SOA policies and procedures. 6.1.9 Develop and Implement SOA Lifecycle Governance The establishment and implementation of SOA lifecycle governance is critical to ensuring that the design and development of new and changed applications are aligned to the SOA strategy and SOA architecture as defined by the organization, and adheres to the SOA policies and procedures developed by applicable governing entities.

SOA lifecycle governance should be tightly integrated throughout the entire SDLC, and various “gate-reviews” should be introduced into the SDLC to govern the design and development of solutions based on the SOA strategy, architecture, policies and standards.

6.1.10 Summary of SOA Governance Strategy outlined earlier: • Establish governance to support interoperability • Establish an Interagency Steering Group (OKDHS, OSDH, OHCA, etc.) • Resource an Interoperability Program Office • Policy and technology standards for data stewardship, security and consent • Seek clarification on federal and state confidentiality rules so information can be shared and used more effectively • Leverage basic building blocks for interoperability including: the Health and Human Service NIEM Domains, MITA, and NHSIA 6.1.11 Ensure Ongoing Partnership between IT and Business The SOA program is an organization wide program, and should be perceived as one by the entire organization.

As previously noted, the program should not be driven purely from an IT or Business perspective, but should be a joint effort from both Business and IT. It is of the utmost importance that employees of the organization perceive the program as driven from both a Business and an IT perspective to ensure that the program receives the required support.

The primary objective of the SOA program should to enable the IT organization to support business processes in an agile and cost effective manner, and this objective cannot be achieved without the full support and involvement of both business and IT stakeholders.

Without visible executive commitment, the program can be perceived as a trivial exercise, and the program will be at risk of not receiving the required support from a prioritization perspective. If the program is perceived as being trivial by the stakeholders within the organization it will be extremely difficult to execute the program successfully.

6.1.13 Provide SOA Training and Certification In order for the adoption and implementation of SOA to be successful, it is essential that SOA training be provided to employees. The SOA training provided will differ from user training, enabling users to utilize the new functionality provided by SOA applications to event driven design training to enable business analysts and developers to better design and develop SOA applications, and adhering to SOA design standards when designing and developing new solutions.

6.1.14 Monitor and Report on Service Performance Throughout the execution of a SOA program at the state of Oklahoma it is important that the benefits realized by SOA be illustrated to all stakeholders involved.

This will assist the SOA program in retaining momentum, stakeholder buy-in and may also assist in securing funds for the future execution of the program. OHCA has already begun SOA implementation, process automation and the implementation of associated services. A key element of defining service specifications is the definition of service levels and expected performance metrics. These service levels and performance metrics are being defined as part of the implementation of processes and services. However, the next step is to monitor and report on the performance of these services, and to identify potential areas for improvement.

6.1.15 Implement Services Using ESB Oklahoma should continue migrating business processes to the SOA architecture as they are currently doing. The complexity and scope of business processes migrated should gradually be increased as the SOA capabilities within the organization mature. Enterprise service bus (ESB) is a good choice for service enablement if the application you’re trying to enable provides an interface to connect it to other systems. A good ESB provides all the tools you need to build XML services that leverage those APIs 6.1.16 Potential Sequence of SOA Initiatives The initiatives described above can potentially be sequenced as indicated in Figure 22 below.

These initiatives are the key SOA initiatives that need to be executed, but not the comprehensive list of initiatives and the roadmap provided should be used as guidance to mature SOA at the state.

In parallel with the initiatives mentioned in this roadmap Oklahoma should continue gradually implementing business processes following the SOA guidelines and principles as they are currently doing. The complexity and scope of the business processes migrated to the SOA architecture should gradually be expanded to incorporate multiple integrated applications spanning multiple business units and thus proving benefit to multiple stakeholders of the SOA program.

Monthly on the 5th OHCA KIDS Interface - Post Medicaid Payments made by OHCA for TFC children External KIDS FTP Manual process for formatting Excel Spreadsheet and ftp'ing data to WebFOCUS. Then run WebFOCUS job to post payments to KIDS Monthly when data become available KIDS KIDS Interface - Child Care External OCCS (Mainframe-IMS) To process all lines of Day Care Services offered and delivered to the child. It captures service provider information and details regarding the particular service. KIDS KIDS Interface - IV-E External AFS Using the Information comes from PS2 to determine if the child is eligible for the IV-E funding.

KIDS KIDS Interface - Contingency Funds External Finance (AS/400) FTP List of Cases Daily M-F KIDS KIDS Interface - Targeted Case Management External Finance (AS/400) Provide Finance with a file of Targeted Case Management Claims Monthly on the last day of the month. KIDS KIDS Interface - IV-E Adjustments External Finance (AS/400) Provide Finance with a file of removed children and their current IV-E status and all children where the status changed during the month. Monthly on the 1st.

OHCA will coordinate with the Federal exchange but not have any control over it. 1 OHCA will intake info and if the applicant is not eligible for Medicaid info will be sent to the exchange. Details unknown at this time.

In addition to supporting the Oklahoma Title IV-D program, OSIS provides automation support to eight Tribal Title IV-D programs. The system currently processes over $300 million in financial receipts and disbursements to child support consumers each year.

OSIS is specifically designed to comply with Title IV-D, associated rules and regulations published in the Code of Federal Regulations, the Office of Child Support Enforcement (OCSE) Systems Automation Guide, Oklahoma state laws, and policies of OKDHS. The system has been in continuous production operation since June 1991 and received federal compliance certification in August 2002. Federal funding for OSIS and supporting staff is based on the Title IV-D Federal Financial Participation (FFP) matching rate established for OKDHS. OCSS submits funding requests annually to Administration for Children and Families (ACF)/OCSE via Operational Advance Planning document process and provides supporting program activity and expenditure reports OCSE-34A, OCSE-157 and OCSE-396.

The operational system is a COmmon Business-Oriented Language (COBOL) application using primarily IBM’s Information Management System (IMS) hierarchical databases with some IBM’s DB2. The system runs an IBM zEC10 mainframe with plans to migrate to a zEC12 platform in May 2013. The mainframe is fiber attached the data center Local Area Network (LAN) which is attached to the OKDHS’ Internet Protocol (IP)–based Wide Area Network (WAN) servicing work locations statewide. Primary production data storage is an IBM DS8300 with an IBM TS7740 virtual tape system backup. Data backup is asynchronously mirrored to an offsite TS7740 for disaster recovery.

To access OSIS, users on the network initiate an IP based TN3270 connection from their desktop using Attachmate’s EXTRA! Non-network system users may access OSIS through the internet with a Secure Socket Layer (SSL) Virtual Private Network (VPN) single user access session. Tribal programs may use the SSL VPN single user solution or may use a site–to–site VPN connection if local printing is desired. Access to specific OSIS functions within the system is controlled through rules defined in the Computer Associates’ (CA) ACF2 security product. OCSS case participants may access OSIS case information through an Interactive Voice Response (IVR) system or through the Internet.

Both methods use web services which directly access DB2 and access IMS

The following outlines OCSS’s functional areas and the interfaces and partnership we have to carry out those functional areas of our program: 1. Case Initiation: Child support must receive a case referral or application for services to begin child support services. We obtain these applications from the general public by filling out the child support application for services which is sent to our State Case Registry for processing. OCSS obtains referrals through various electronic interfaces. For Title IV-E Foster Care, Temporary Assistance for Needy Families (TANF), child care, Non–Title IV-E and some Medicaid referrals, OCSS has an interface with AFS.

For some Medicaid referrals, OCSS has an interface with OHCA. OCSS also receive referrals from our federal partners through our electronic Child Support Enforcement Network (CSENet) interface. Additionally, paper referrals for all other states, territories and foreign nations are mailed directly to our State Office Central Case Registry. 2. Locate: Once a child support case is established, services are provided to locate the non–custodial parent and certain assets. Types of activities included but are not limited to tracking their residence through an interface with a vendor representing the United State Postal Service (USPS), searching OKDHS records through our interface with the AFS PS2 system, checking driver’s license records through our interface with the Department of Public Safety (DPS), checking many records from all other Title IV-D programs nationwide through our interface with the federal OCSE Federal Case Registry and checking employment information from the Oklahoma Employment Security Commission (OESC).

3. Establishment & Paternity: For married and separated cases, OCSS will establish a child support obligation through the local court systems. For cases requiring the establishment of paternity, OCSS offers services to conduct genetic testing of the case participants to gather scientific evidence on the probability of the father. The local court systems make the final determination of the legal responsibility of the father. This information is manually feed into the OSIS system.

4. Enforcement: When a non–custodial parent fails to honor a child support court order and is not making child support payments as instructed, the OCSS program and the automated system have many legal remedies available to compel the non–custodial parent make regular payments. Those legal remedies included but are not limited to credit bureau reporting by having an interface between OSIS and each credit bureau agency to report debt, Internal Revenue Service (IRS) and Oklahoma Tax Commission (OTC) interfaces that allow OSIS

5. Medical: OCSS gets automated electronic referrals from AFS and OHCA for households that have been determined eligible to receive medical assistance. Most of these referrals receive the same activities as a case OCSS would receive through the application for service process. In addition OCSS collects cash medical “premium assistance” and reimburses the OHCA for some medical expenses. OCSS also works with the local court systems to obtain medical orders to ensure the children have medical insurance. 6. Interstate: All Title IV-D programs are required to accept and work cases from all other Title IV-D programs.

As stated earlier OCSS receives both paper and electronic referrals from other Title IV-D entities. For the most part OCSS works these cases just like they would for an Oklahoma application for services. 7. Finance: The most technically complex part of the automated system and program is the financial component. Child support collections come in from all of the automated enforcement remedies mentioned above, directly from non– custodial parents, and from other states that collect on our behalf into the OCSS State Disbursement Unit (SDU). The SDU uses an electronic interface to transmit all payments received to OSIS for distribution processing.

All payment exceptions are moved to a hold area and manually resolved by staff but the majority of payments are automatically issued to families through electronic interfaces with Xerox and Open System Technologies (OST). Within this financial area OCSS must submit federal reports like the OCSE–34A, OCSE–157 and OCSE–396 that tie to OCSS reimbursement and funding. 8. Case Management: OCSS staff manages the life of a child support case by handling specific activities like moving the cases from functional area to functional area as needed. They also adjust the court orders as situation change in the life of the custodial or non-custodial person.

Court hearings and appointments are also managed in this functional area. If additional events occur that require the closing of a child support case, those heavily regulated closure reasons are documented here.

9. Security & Reporting: OSIS has special requirements in the area of security to ensure the data we collected is secure and safe and being viewed by the appropriate individuals. Security decisions are made by the OCSS program and then OMES security makes the physical changes to the access permissions. Reporting is critical for the OCSS program since program funding is dependent on it. The annual OCSE–157 and Oklahoma Advanced Planning Document (OAPD), and the quarterly OCSE–34A and OCSE–396 are what drive our funding for the program. OCSS use or interface with the AS400, Relational Database Service (RDS), Document Direct and WebFOCUS to support reporting needs.

It performs eligibility for: • SNAP • TANF • Child Care • Title II and XVI • Medicaid • Medicaid Home and Community Based Waivers Energy Assistance • Title V programs It contains services related information as it relates to the client’s health and welfare for the following divisions: AFS, OCSS and DDSD. This is a 24/7 system which includes: • Applications for processing case number assignment • General client demographic • Financial and family assistance

• Data Exchange: Online and batch file processing system from which OKDHS performs information data exchanges with Federal partners and other entities.

• Electronic Payment Systems (EPS) (Electronic Benefits Transfer (EBT), Electronic Child Care (ECC) & Electronic Payment Card (EPC)): Process to electronically transfer financial benefits, SNAP benefits and child care authorizations to clients and provides them via debit cards. • Family Assistance: Disabilities assistance program is a cash payment program for families who are caring for children under age 18 at home. • Financial Activities: Maintains on–line five years of case food benefit and warrant issuance information; provides on–line inquiries for this information; provides the vehicle for re–issuing documents which have been returned; provides for supplemental issuance; and provides for recording of reconciliation information.

• Future Actions: Provides for the storing and executing of transactions on a preset date and time. • Low Income Home Energy Assistance Program (LIHEAP): This program is to provide assistance to eligible households to meet the costs of home energy that are excessive in relation to household income. • Notices: This maintains all relative information about all notification letters (notices) which are related to a case and sent to clients and/or vendors. • Level of Care and Plan of Care: Determines the level of care a client needs so that a plan of care may be developed for people with Developmental Disabilities.

1.2.1 Family Assistance and Client Services (FACS) FACS is the software used by OKDHS staff to update and maintain AFS case information. FACS is a “front end” to the PS2 System. The primary purpose of the FACS software is to gather information, send it to PS2 (through a clone of the ff transaction called fu) or DB2 as appropriate and display a response from PS2 and DB2. Other features in FACS include Case Notes, Case Status Monitoring, and Notice Generation. It provides a Graphical User Interface (GUI) which allows the user to navigate through tabs designed to follow the flow of an applicant interview.

Through this GUI the user can enter information through “free form” fields, check boxes, or select options from drop-down fields. This is considered to be an improvement over entering the information on the PS2 “green screens”, which required the user to follow a strict format and required that the user knew the PS2 codes values, as opposed to selecting a description from a drop-down field.

FACS is written in Sybase’s PowerBuilder. The first version of FACS went to production in December, 1996. The software is now considered to be a legacy application. FACS is a client/server based application (which means that it runs from the local county office server) as opposed to a web based application (which would run using web technology from one central site). Most new generation software development is done with web based software (such as .NET or C# (C Sharp)). Figure C-5 illustrates the AS-IS Eligibility and Enrollment data exchanges for AFS.

SACWIS is a comprehensive automated case management tool that supports social workers in foster care and adoptions case management. SACWIS is intended to hold the State’s “official case record”, which is a complete, current, accurate and unified case management history on all children and families served by the Title IV-B/IV-E State agency. The software application was created in 1994 and deployed statewide to the field in May 1995. The acronym for the Case Information and Data System (CIDS) was aptly changed to KIDS. KIDS is a Windows based two-tier client server application with the front end using Sybase’s PowerBuilder 11.5 and the back end database using Oracle

The instance of the application runs on an endpoint device connected to a single large database via a WAN. Remote access to the system can be achieved through a server farm via a web based portal. It provides essential support to the CWS in their mission of improving the safety, permanency and well–being of children and families involved in the Child Welfare system. The KIDS application uses Global Name Recognition (GNR) for name search. The system is tightly integrated in the operations of CWS. The statewide hotline uses the system for logging calls, and distribution to local offices. Investigation and Permanency Planning documentation is all entered into and retained in the system, and is used in court for case presentation.

eKIDS is a Windows based web enabled subset of the KIDS Application developed with Active Server Pages (ASP), JavaScript, VBScript, HyperText Markup Language (HTML), Cascading Style Sheets (CSS) and SQL (Structured Query Language) using an Oracle database. It allows online access of selected Child Welfare information to CWS partners. These partners include Native American tribes, Oklahoma Children's Services (OCS) contractors and liaisons, court officials: judges and district attorneys, school–based social workers, and child support enforcement personnel. KIDS Application Help Desk (KAHD) is a Windows based two–tier client server Help Desk support application with the front end using Sybase’s PowerBuilder and the back end database using Oracle.

The KAHD application is used as an incident and response tracking system and also supports software development life cycle for the KIDS application support team. Apart from tracking problems, it logs client requests and/or enhancements to the KIDS application. The KAHD application is available to the KIDS Technology and Governance and the KIDS development teams providing an organized method for documenting and reviewing the KIDS application as to: Operational anomalies, application enhancement requests, KAHD's associated with an identified screen, and all KAHD's associated with a specified business function.

The CB supports the development of state and tribal child welfare reporting systems to enable the collection and analysis of important information about children and families, as well as improve case practice and management. • AFCARS on all children in foster care and those who have been adopted with Title IV-E agency involvement. Title IV-E agencies are required to submit AFCARS data twice a year. • NCANDS is a voluntary data collection system that gathers information from all 50 states, the Washington, D.C., and Puerto Rico about reports of child abuse and neglect.

• NYTD collects information about youth in foster care, including outcomes for those who have aged out of foster care.

This data is collected, validated and transmitted periodically to the CB on a routine scheduled basis. In addition, there are additional “audits” performed on a periodic basis varying from annually to every few years. These audits include a Title IV-E Financial Review. The purpose of this review is to assess payment accuracy through an examination of case record documentation (both physical and electronic case files). Another audit is the CFSR which enables the CB to ensure conformity with Federal child welfare requirements, to gauge the experiences of children, youth, and families receiving State child welfare services, and to assist States as they enhance their capacity to help families achieve positive outcomes.

The following resources provide results and lessons learned from the CFSR’s and address the implementation of the CFSR process in the United States:

These contractors are called OCS contractors. They have access to the KIDS database via web based application called “eKIDS” (ASP.NET Passport). OCS contract workers log into the system via the internet and have access to limited data and can enter documentation of their case work activities directly into the KIDS database via eKIDS. Native American tribal workers also have the ability to enter limited case documentation of their activities via eKIDS.

• There are other community external partners who also have more direct and timely access to KIDS data via eKIDS (ASP). This system is separate from the one used by OCS contractors and less complex being limited to structure “Read only” capacities. They do not have the ability to enter data into the system. These external partners include Juvenile Judges, District Attorneys, School Based Social Workers, and Post Adjudication Review Board (PARB) members. • There are multiple additional external parties that can have access to CWS data on a prearranged or ad hoc basis. They include the previously mentioned CB entities (CFSR, Title IV-E Audits, AFCARS, NCANDS, and NYTD).

Universities, colleges, schools and researchers from public or private agencies can request data and receive it via various types of electronic means if there is an approved data sharing agreement. Various reports are available to the legislature, students, general public, and the Pinnacle Plan Co-Neutrals (monitors of a federal lawsuit settlement agreement).

• Other sister divisions in OKDHS have workers crucial to the delivery of CWS services. They include: Social Service Specialists, Departmental Disabilities Services Division (DDSD) Case Managers, Child Care Licensing Specialists, Child Support Specialists, Social Service Inspectors, and Adult Protective Services Specialists. Some of the CWS related work they perform includes Foster Care Payments, Child Support, and Paternity Determination, Title IV-E

This program, known as Medicaid, became law in 1965 as a cooperative venture jointly funded by the Federal and State governments (including the Washington, D.C. and the territories) to assist states in furnishing medical assistance to eligible needy persons. The MMIS was developed by Hewlett Packard Enterprise Services (HPES) to serve the needs of the federally mandated program for all states. It is Healthcare Financing Administration (HCFA) certified and has been operational since 1995. MMIS is a highly sophisticated, feature–rich system centered on a strong, Medicaid–specific relational data model.

It divides the application into components which may be processed on multiple networked computers. This design and supporting architecture deliver enhanced flexibility, scalability, and reliability, as recognized by the National Association of State Information Resource Executives (NASIRE) Award for innovative use of technology that the system received after its implementation in the State of Indiana. The

Experience has shown that SAN devices provide more efficient use of space and the device can be managed from a single console. A second SAN unit will act as a geographically dispersed electronic vault site creating a much faster disaster recovery response.

Referring to the Figure C-9 below, the system is logically divided into three primary components: • Claim Engine is responsible for receiving interactive transactions from external sources, adjudicating them, and returning the appropriate response. • Online/Batch Application is responsible for maintaining and reporting on data contained within the online database. • History and Back–End reporting component is responsible for analyzing, reporting, and supporting the management of the activities that have occurred in the two front–end systems.

The external interfaces describe a variety of data sources which influence processing within the system.

The External Data Submission Entities are organizations that supply information to the MMIS. PS/2 is the primary source of recipient eligibility information. HCFA is a federal organization that supplies many different types of data feeds.

Primary entry points to the systems include direct local connections (for onsite staff), dedicated VPN tunnels (for remote staff and external trading partners), the Internet, and the newly implemented HP Healthcare Network Cloud (HNC). The HNC is a private, fully secure, national network that provides Electronic Data Interchange (EDI) and intranet connectivity between OHCA and national HPES Healthcare and Business Process Outsourcing (BPO) sites. The internet connection is the primary entry point for providers, other state agencies, and provider representatives.

The bulk of OSDH’s systems are designed for capturing, tracking, and reporting information, and mostly for non–clinical purposes. A few are used in providing both clinical and non–clinical services. The most common business processes supported by OSDH systems are data capture/collection, data management, data analysis, tracking, and data reporting. Some systems additionally support limited case management functions, threshold identification, and

All of the systems supporting direct client services have been migrated into PHOCIS. Few systems have direct interfaces that allow data to be sent/received between systems with no human intervention. Of the small numbers that are automated, only a few are set up to utilize Health Level 7 (HL7) formats. Figure C-13 provides a functional look at the OSDH Vital Records, Birth Registration Workflow. Birth information to OCSS – It is the interface where birth information is sent to OCSS with Personal Identification Information (PII) removed. The file is kept at a File Transfer Protocol (FTP) site for pickup by OKDHS.

Birth data cannot be used for Master Person Index (MPI) purposes in the Enterprise Service Bus (ESB) because there’s a state mandate that allows the sharing of such information only for certain purposes as defined in the mandate. Since it is a State mandate even sharing this data with security in place would be against the law. The Vital Records for a birth has a Birth Certificate Number and a Record Number attached to it but it is internal to the system. The Death System has a different unique identifier. The Record Number and Birth Certificate Number is not a unique identifier that is used throughout the systems.

Demographics data from OSDH is used by OHCA’s (HPES) to partially complete new applications. OHCA’s (HPES) web service returns to the PHOCIS web service an “ATN” and a URL/link which is used by the PHOCIS web service to make an HTTPS “Post” call to the OHCA’s (HPES) web service. If it is a new application, OHCA’s (HPES) returns a new ATN when the web page is requested.

PHOCIS users complete the SoonerCare application and submit it. Once a completed SoonerCare application is submitted by the user, OHCA’s (HPES) web service returns to OSDH an XML file containing the contents of the SoonerCare application.

Only completed applications are sent to OSDH. For each application approved/changed, the SoonerCare application is sent to OSDH from the OHCA’s (HPES) web service(s). These transmissions occur in real–time. The record sent contains all of the agency fields as well as the OHCA determined data. OSDH stores these in the OSDH-NWD database by inserting new applications or updating existing applications: • Citizen verification – batch data exchange • Batch data exchange between OSDH and OHCA of data to verify citizenship. • OHCA sends a file requesting checks to be made. OSDH returns a file of results.

OCSS obtains orders and collects payments that are forwarded to OHCA to offset the cost of the Medicaid program. OCSS has a very similar relationship with AFS and CWS. Case referrals are received and information is shared between the programs on case participants, child support orders and payment information, CP cooperation, and benefits expended. OCSS retains child support payments when an assignment of support rights is in effect and forwards retained collections to the Title IV–A and Title IV-E programs. OCSS also retains child support payments in Non–Title IV-E foster care cases and forwards these to CWS.