Att K - Statement of Work.docx

EXHIBIT B

SUPPLEMENTAL DEFINITIONS

Table of Contents:

I. EXECUTIVE SUMMARY

1.0 Overview of Statement of Work

This Statement of Work (“SOW”) is part of the contract between the Contractor and the State for the provision of a Pharmacy Benefits Administrator (PBA) system and services as detailed in RFP 27-88864. A Pharmacy Benefit Administrator (PBA) is the entity responsible for administering the State’s fee for service Medicaid pharmacy benefit in accordance with State-defined policies, program requirements, and reimbursement methodologies. A PBA administers the pharmacy benefit under State direction, unlike a Pharmacy Benefit Manager (PBM) which exercises broader discretion over pharmacy benefit design, pricing strategies, and formulary management. This SOW is also attached to RFP 27-88864 for reference and to aid Respondents in the development of their proposals. The proposals should adhere to the instructions in Attachment F - Technical Proposal Template.

II. BACKGROUND AND CURRENT STATE

The State currently contracts with a PBA to administer its fee for service Medicaid pharmacy benefit. This SOW is largely focused on the requirements pertaining to the fee for service Medicaid pharmacy benefit. Additionally, the SOW outlines several possible expansions of the Contractor’s scope that are still under consideration.

III. SCOPE OF WORK

A. OBJECTIVES OF ENGAGEMENT

2.0 Duties in this Statement of Work

The tasks, responsibilities, expectations and obligations set forth in this SOW represent the duties of the State and the Contractor under this Contract. Some duties of the State or Contractor are listed in tables of ‘responsibilities’ and specifically numbered below; however, not all duties are captured in these tables. A duty or responsibility need not be specifically listed and numbered in a table to be enforceable. The numbered tables are provided for ease of reference and do not enhance, or detract, from the enforceability of any duty in this SOW regardless of its placement in a table.

2.1 State Approval of Duties

Many duties set forth in this Contract require State approval of Contractor work. Sometimes the requirement of State approval is listed in a table of State responsibilities. Regardless of whether State approval is listed in a table of State or Contractor responsibilities, or in the narrative section above, or both, the Contractor shall be responsible for seeking State approval where required.

State approval of Contractor work associated with tasks, responsibilities, and deliverables does not in any way relieve the Contractor from full financial responsibility for Contractor work products that do not meet the State requirements, as set out in this SOW.

3.0 Key Performance Measures and Contractor Performance

Twenty Percent (20%) of the Contract’s monthly cost for the Maintenance and Operations phase of the PBA shall be allocated to a performance incentive pool. The funds in this pool shall not be automatically earned by the Contractor but shall, instead, be earned by the Contractor through quality of its performance, which shall be continuously monitored by the State and Contractor.

The quality of Contractor performance shall specifically be measured by Key performance measures (KPMs) which are presented in tables throughout this SOW. KPMs identify the service quality the State is requiring, along with the measurement and the acceptable service level threshold of performance.

In some sections (Sections 5, 12.4, 15, and 16) the Key Performance Measures are identified in their own table separate from Contractor Requirements. In other sections (Sections 6 through 11, 17, and 18) all the Contractor Requirements are considered Key Performance Measures and a separate listing distinct KPMs from Contractor Requirements is not presented. In both of these iterations each measure is assigned an Impact Severity. Thus, a KPM is identified below by the assignment of an impact severity number (and not necessarily its separate articulation in a table labeled Key Performance Measures).

During each month, the funds potentially earnable by the Contractor in the performance incentive pool shall be reduced for each KPM missed. Specifically, if the Contractor fails to meet a KPM, the State will deduct the appropriate funds from the Contractor’s performance incentive pool quarterly claim according to the schedule below. The reduction is final – the amount of the performance incentive pool reduced may not be earned back (though the State reserves the right, in its sole discretion, to waive the deduction for a KPM).

In the event of a dispute of responsibility for the Contractor’s failure to meet any performance requirements, the State may utilize the services of an independent party such as the IV&V vendor to analyze and determine where responsibility rests. If it is determined that responsibility does exist with the Contractor, then the Contractor shall deduct the funds for both the missed measure and the cost of the analysis from its performance incentive pool monthly claim.

The amount of the deduction shall accrue each month the Contractor fails to meet each key performance measure. Each month, the total deduction will equal fifteen thousand dollars ($15,000.00) multiplied by the total number of each unmet key performance measure.

For example, failure to meet one (1) key performance measure for three (3) months could result in a deduction of fifteen thousand dollars ($15,000.00) multiplied by three (3) months to total forty-five thousand dollars ($45,000.00). Failure to meet two key performance measures for three (3) months could result in a deduction of thirty thousand dollars ($30,000.00) per month multiplied by three (3) months to total ninety thousand ($90,000.00).

Seven thousand five hundred dollars ($7,500.00) multiplied by the total number of calendar months of the failure may be deducted for each subsequent calendar month the same key performance measure is unmet.

For example, failure to meet one (1) key performance for two (2) months could result in a deduction of seven thousand five hundred ($7,500.00) multiplied by two (2) months for a deduction of fifteen thousand ($15,000.00).

One thousand five hundred dollars ($1,500.00) multiplied by the total number of calendar months of the failure may be deducted for each subsequent calendar month the same key performance measure is unmet.

For example, failure to meet one (1) key performance measure for two (2) months could result in a deduction of one thousand five hundred dollars ($1,500.00) multiplied by two (2) months for a deduction of three thousand ($3,000.00).

five hundred dollars ($500.00) multiplied by the total number of calendar months of the failure may be deducted for each subsequent calendar month the same key performance measure is unmet.

For example, failure to meet one (1) key performance measure for two (2) months could result in a deduction of five hundred dollars ($500.00) multiplied by two (2) months for a deduction of one thousand dollars ($1000.00).

Deductions in performance incentive pool payments are not damages and do not preclude the State from assessing state incurred actual damages resulting from the Contractor’s deficiencies in performance. Deductions represent a failure to earn incentive payments.

4.0 Technology and Project Management

The Foundation Requirements section of this SOW presents the elements that set the overall standards and methods to be employed throughout the duration of the project, including the development of the PBA system and the maintenance and operations of the system thereafter.

The purpose of this section is to describe the Foundation elements and provide corresponding responsibilities of the State and the Contractor. This section includes the following:

· System Solutions

· System Development Life Cycle (SDLC)

· Systems Environment

· Technical Standards

· Testing

· Business Continuity and Disaster Recovery

· Data Conversion

· Privacy Standards

· Security

· Training

· Documentation

· Facilities

· Engagements and Transition

· Medicaid Information Technology Architecture

4.1 System Overview

This Contract acquires systems and solutions to align with the Indiana Health Coverage Programs (IHCP) pharmacy benefit needs. Pharmacy Benefit Administration is comprised of the following services:

· Service desk management including pharmacy prior authorization (PA)

· Pharmacy claims processing (including development and maintenance of benefit rules and required reference files). The Contractor is responsible for processing pharmacy claims, defined as National Council for Prescription Drug Programs (NCPDP) claims and compound prescription claims

· Pharmacy financials (accounts receivable, federal financial participation (FFP) accounting, accounts payable to include claims payments)

· Federal and state supplemental drug rebates

· Drug related medical supply rebates

· Board(s) and committee(s) support

· Drug utilization review (DUR)

· Reporting including, but not limited to CMS-64, Quarterly Drug Rebate Report, Monthly Update Report, Quarterly Clinical Report, CMS DUR Annual Report

· Pharmacy audits

· Rate setting including State Maximum Allowable Cost (SMAC) rates and covered OTC Drug MAC rates

· Preferred drug list (PDL) development and management

· Indiana Medicaid pharmacy benefit cost containment strategy Indiana’s goal is to continuously reengineer business processes to align them to industry best practices. The Contractor is required to strive to reengineer business processes as well as enable and, as requested by the State, assist Indiana in reengineering State operated business processes utilizing the technology and tools from this Contract. As such, the Contractor must have the necessary knowledge and experience in implementing and operating systems and services that fully meet the goals and objectives of the MITA business process model. The State expects that the Contractor will know and articulate explicitly how best to implement its processes to support this objective.

All external and inter‑system interfaces shall use the State’s MuleSoft API Gateway with OAuth 2.0 (client credentials for system‑to‑system; OIDC for user flows), mTLS (TLS 1.2+), JSON schema registry, standardized error taxonomy, and GoAnywhere Managed File Transfer (MFT). The Contractor shall utilize these technologies for interfaces unless an exception is approved by IOT and shall align with IOT’s API‑led standards and data‑exchange policies.

The Contractor must comply with all state and federal laws and regulations, including but not limited to the Americans with Disabilities Act (ADA), the Balanced Budget Act (BBA) of 1997 Subtitle H, and the Medicaid Managed Care rules, 42 CFR 438. The Contractor must be compliant with Health Insurance Portability and Accountability Act (HIPAA) and NCPDP. In addition to these federal regulations and statutes, federal civil rights laws will also govern the principles of this procurement.

The Contractor must identify and provide documentation to the appropriate State program or fiscal staff, for all systems and modules designed, developed, installed, or enhanced with a ninety (90) percent federal financial participation (FFP) match, to validate that the systems can be operated by various contractors or other users.

4.1.1 Data Warehouse/Decision Support System/Business Intelligence (DW/DSS/BI) While the Contractor will not be dependent upon the Enterprise Data Warehouse for operating purposes, the Contractor will push data to the data warehouse and, at times, may be required to pull data from the data warehouse in order to fulfill business needs.

The Data Warehouse/Decision Support System/Business Intelligence (DW/DSS/BI) will be comprised of the following:

a. Medicaid data warehouse, decision support, and business intelligence tools to produce:

1. Federal reports and Management and Administrative Reporting (MAR)

2. Operational reports (program performance measurement, including but not limited to trending and forecasting)

3. Program Management Reporting using health care data as available through the advancement of Health Information Technology (HIT) in the State

b. Clearinghouse, functioning as the staging, ETL (extract, transform and load) and cleansing clearinghouse for data conversion

4.1.2 Medicaid Enterprise Stakeholders

The primary stakeholders of this procurement are:

a. State staff who manage and operate business processes of the IHCP pharmacy benefit program

b. Providers of covered services to Medicaid members

c. Members who are recipients of Title XIX and XXI services

d. Centers for Medicare & Medicaid Services (CMS) In addition, the State continues contractual arrangements for other services that comprise the Indiana Medicaid Enterprise. Below is an example of the vendors that provide services and will interact with the Contractor and are therefore, considered stakeholders of this Contract:

a. Enrollment Broker

b. Fiscal Agent

c. Enterprise Data Warehouse Other stakeholders who are impacted by this Contract include:

a. Indiana legislators

b. Provider associations

c. Member advocates The comprehensive lists of Foundation, Function and Business Process responsibilities and requirements provided in this SOW were derived primarily from the current State business activities in conjunction with input from the State subject matter experts (SMEs). The State expects the Contractor to have a complete and thorough understanding of the pharmacy business and all business processes required to execute and manage a successful Pharmacy Benefit Administration System. The Contractor shall also have a defined process for including the aforementioned stakeholders in design, development, and implementation processes.

The Contractor shall demonstrate a complete understanding of the Medicaid Enterprise to develop a Pharmacy Benefit Administration system that meet the State’s business needs while embracing the MITA goals and objectives.

4.1.3 Flow of Pharmacy Claims Data Between State Systems and the PBA The PBA both creates and receives pharmacy claims data, and this data is shared with different State systems. Currently, the Enterprise Data Warehouse is the State system with which the PBA interfaces regarding claims data receipt (for the purpose of processing rebates related to MCO claims as described herein) or the provision of claims data to the State. The Table below describes the flow of this claims data to the EDW (with the PBA claims being the FFS claims).

As the State evolves its programs this flow may change. Specifically, the State is considering a revision for the flow of FFS/POS claims to require the PBA to simultaneously make parallel submission of this data to both the EDW and MMIS.

The claims data the PBA receives from the EDW takes the form of a standard Medicaid extract.

4.1.4 PBA Interface with the State’s MMIS

The PBA will be required to interface with the State’s MMIS for a number of purposes including, but not limited to, provider and member enrollment and eligibility issues.

4.2 System Development Life Cycle (SDLC)

The Systems Development Life Cycle (SDLC) is designed to create a high-quality system(s) that:

a. Meets or exceeds customer expectations

b. Reaches completion within time and cost estimates

c. Works effectively and efficiently in the current and planned Information Technology (IT) infrastructure

d. Is cost-effective to enhance and inexpensive to maintain The SDLC phases serve as a programmatic guide to project activity and provide a flexible but consistent way to conduct projects to a depth matching the scope of the project.

However, the Contractor may propose an alternate approach to meeting the objectives of the SDLC phases identified below, including approaches such as Rapid Application Development (RAD), Rational Unified Process (RUP), Agile development. Any alternate approach must be submitted to the State with sufficient time for review, and approved in writing by the State, prior to implementation Each of the SDLC phase objectives is described in this section with key deliverables, a description of recommended tasks, and a summary of related control objectives for effective management.

At the State’s discretion, the SDLC will be modified to ensure the development process is as effective and efficient as possible while still meeting the stated project goals and objectives.

4.2.1 Phases

4.2.2 Testing

The Contractor shall conduct unit, system, interface, performance, and regression testing as well as facilitate/coordinate user acceptance testing per policy and procedures approved by the State. Testing responsibilities include, but are not limited to:

· Comply with industry standard SDLC testing standards.

· Provide component and integration testing that is designed to ensure that all components, data feeds, identity management solutions, etc., work together properly and, as a whole, meet the business and functional requirements of the system.

· Provide system testing that shall include the development and use of automated system test scripts to validate that the system operates in accordance with the design specifications, for example:

· User roles are performing properly

· Authentication performs properly

· Workflows perform properly

· Data flows perform properly

· For User Acceptance Testing (UAT), the Contractor shall schedule and facilitate State-selected users to complete UAT, track their results, and present results to the State for review prior to requesting authorization for production releases.

· Conduct testing and ensure that the modifications or enhancements are completed with 100% positive results and receive approval from State designee(s) before activating any modifications or enhancements. If there are minor issues (i.e., resulting in less than 100% positive results), the State may choose to approve the modification or enhancement release. In those situations, the Contractor shall be responsible for resolving issues on a State-approved timeline post release.

4.2.3 State Responsibilities

4.2.4 Contractor Requirements

The Contractor shall:

4.3 Systems Environment

The environment will follow the standards identified by the State. The Contractor may recommend alternate approaches to the environments prescribed below; however; the State retains sole authority to approve or deny such variation. Prior approval for variation must be obtained, in writing, from the State’s authorized representative.

4.3.1 Production Environment

Production contains all of the sub-environments required to serve different types of users including, but not limited to, end-users, developers, and trainers.

Given its broad reach, availability of each sub-environment (Delivery, Staging, Control, or Project) is essential and each needs to be amply supported and carefully managed.

Below are the details of each production sub-environment.

4.3.1.1 Non-production Environment Data Requirements

All non‑production environments (e.g., DEV, QA, UAT, SIT) must exclusively operate on masked, tokenized, or synthetic data.

No raw, unmasked production data may be imported into or referenced within any non‑production system under any circumstance.

4.3.1.2 Mandatory Data‑Masking Validation Prior to Promotion

Each deployment pipeline must include automated pre‑deployment validation checks that confirm all required masking jobs have successfully completed.

Promotion to higher environments (including staging and production) must be blocked if:

· Any masking job fails,

· Any dataset remains unmasked or partially masked, or

· Validation logs cannot be produced or verified.

Deployment systems must generate clear failure messages and audit evidence when a promotion is halted due to masking non‑compliance.

4.3.1.3 Audit Trail Retention Requirements

Full audit trails (including masking job logs, validation results, and deployment gating decisions) must be retained according to the following schedule:

· Ninety (90) days online retention for rapid access and review.

· Ten (10) years archived retention in compliant long‑term storage, with retrieval procedures documented and periodically tested.

Archived audit logs must maintain immutability protections that prevent deletion or modification.

4.3.1.4 Delivery Sub-Environment (Go-Live)

Delivery is the main user environment. It is what most people will see and is called the “Production” environment. However, actual “Production” includes all three environments (Delivery, Staging and Project). Barring unforeseen circumstances, all of the work done by users will be accomplished in this environment.

4.3.1.5 Staging Sub-Environment (Disaster Recovery)

a. The Staging sub-environment is considered a “Production” environment because it must always be ready to act as the Delivery environment, as necessary. For this reason, Staging must be an exact duplicate of the Delivery environment, i.e. all hardware and software must be duplicated

b. With the use of Staging as a disaster recovery solution, it must be located in a different geographic location than Delivery, which must be approved by the State

c. Staging must be cloned regularly from Delivery and used as the final test environment before a change goes into effect on Delivery

d. Any change must be rigorously tested in either or both the Project and Validation environments prior to being applied to Staging

4.3.1.6 Control Sub-Environment

The Control sub-environment holds the out-of-the-box solution, the latest FSSA specific solution, and all history of that solution. This information is captured in the three types of environments listed and described in detail below:

a. Commercial Off-the-Shelf Environment (COTS Only): This will contain an unmodified version of the base technology used in the solution (out-of-the-box). The purpose of this environment is to determine, in certain cases, the root cause of a problem. Often, this may be the only way to distinguish between a problem in the root product and a problem with an extension to that “out-of-the-box” functionality. This environment also allows comparison of how different the FSSA solution is from the base product.

b. Gold Environment: This is the latest version of the solution excluding all business data. It will be built as the major areas of the solution are tested and validated. Once all major areas of the solution have been added, Gold will be the environment cloned to create new environment instances.

c. Orchestration/Management Environment: This is used for

1. Requirements management

2. Issue/incident/process management

3. Version control

4. Test management

5. Testing

6. Build management

7. Release management It supports the creation and management of every other environment instance as well as the revisions, both past and present, of the solution itself. This includes all Production and Validation environment instances and all aspects of the solution as it relates to configuration and extension of the base tools.

4.4.1.7 Project Sub-Environment (Maintained after Go-Live)

Several sub-environments are included under the main project environment. These environments are set up and dismantled based on the plan put together by the project team.

It is essential that these environments stay operational during the project to facilitate the development of the solutions that will reside on this infrastructure. Thus, they are considered Production sub-environments along with Staging, Delivery, and Control.

4.4.1.7.1 Development Environment

This will support the development of the solutions. As such two basic types of development environments are required:

a. Individual Development Environment: These environments are necessary for developers to experiment and regression test solutions. These solutions can and will require the developers to control much if not all of the environments. In order to support these developers adequately, a very personalized version of the base environment must be developed and updated as the solution evolves. These environments must be supported by the developer at least at a basic level (start/stop instances, minor configuration changes, etc.). Help must be available for these individuals in the case of a large problem. There must be a means and methodology of recreating the developer’s environment in short order without major work disruption to the developer or the support representative.

b. Development Integration Environment: These environments are used to initiate the integration of the individual team member’s solutions. All solutions for a given set of functionalities must work together as well as separately or the solution as a whole fails.

4.4.1.7.2 Test Environment

This supports the testing of the solution. As such there are two basic types of environments that are required:

a. Business System Test Environment: These environments are used to test the entire solution from start to finish, focusing on the success of the developers in adhering to stated requirements. These test environments are very similar in nature to a large Development Integration environment that encompasses all functionality of the solution. However, the difference between Business System and Development Integration is in the number and nature of the tests and testers. The Business System Test environment encompasses the whole solution and will utilize a number of testers to focus on testing the solution. These tests will cover all major scenarios of the solution. Subsequent rounds of testing will be initiated in quick succession with changes implemented based on previous test results of both the Business System and Performance tests. These environments will be rebuilt several times and in some cases several environments may need to overlap.

b. Performance Test Environment: This should be set up to emulate the planned Delivery environment. This may be accomplished by setting up the Delivery or Staging environment early and using it to accomplish the performance testing.

Several iterations of these tests are expected and they will involve the utilization of an automated testing tool to simulate high volume or “load” testing. The test results will be evaluated, changes made by developers, and the same tests run again. As Business System testing changes become available they will also be included in the Performance environment.

Once the initial go-live has been completed, the Validation environment will be used to emulate the conditions of the Delivery environment in order to complete follow-up projects that require performance testing.

4.4.1.7.3 Training Environment

This will support the training of both users and support personnel in the solution. As these are widely diverse areas of training, two types of environments are required:

a. User Training Environment: This environment has the same requirements as the Business System Testing environment with the latest copy of the solution and any training data loaded. However, the training environment will be re-built periodically and after each round of classes. It will be one of the environments to survive after go-live. Training should be available during the life of the entire solution.

b. Support Training Environment: This environment should be set up to closely resemble Delivery without replicating all the hardware of Delivery. Support personnel only require information on the hardware and software setup work and actions to be taken in case of difficulties.

Like the User Training environment, the Support Training environment will be re-built periodically and maintained after go-live.

4.4.1.7.4 Data Conversion Environment

This environment will support the conversion and migration of all legacy system data into the PBA. It will also support the transition testing (Mock Testing) of which data conversion and migration are a part.

a. Data Validation Environment: This environment supports the conversion and migration of all legacy system data. It is the environment that will be used to ensure that the legacy data has been mapped to the new solution correctly and accurately using a massive sampling effort. It will also serve as the data migration development environment.

b. Mock Environment (Transition Testing): This environment supports the testing of both data migration and all other transition efforts large and small. The early Mock environments can be a virtual representation of the Delivery environment. However, during the later Mock tests, the Mock and Delivery environments must both be as close to identical as possible. This environment will also be used to conduct “what if” analysis in the development of policies and procedures.

4.3.2 Production Environment Interactions

The building of environments and management of environment changes are vitally important to the continued success of the project.

Special regard must be paid to version control, management of tests and change implementation. For this reason, release management software will be considered part of the infrastructure requirements defined in Section 4.4, Technical Standards. Details of the proposed approach should be provided in the Configuration Management Plans of the response. However, the environment specific areas are covered in the following diagram and sections.

a. Building Environments: The first environment to be built should be the Control environment (Out-of-the-Box, Orchestration /Management, and Gold). It will be the source of all other environments. All changes intended for an environment should first go through the standard build and change process. This is vital for version control.

b. Change Process by Environment: The first environment to see any given change will be the Individual Development environments. Once the change has been unit tested, it will be packaged and added to the Control environment. From the Control environment it will be applied to the Development Integration environment.

After successful integration testing, the change will be moved to the current Test environment. Subsequently, when all testing has been successful, the change will be moved to the Gold and Training environments and all developers will be notified that individual development environments need to be updated.

From there it will be moved to the Staging and Delivery environments. The Staging and Delivery environments should not be involved until the initial go-live has been accomplished.

4.3.3 Validation Environment (Maintained after Go-Live)

This environment will contain a scaled down, less complex version of the Delivery environment. This environment is used primarily to make and test major hardware and software infrastructure changes to the solution.

Validation will support a much smaller group of users than Production and will be accorded a lower priority. Management of this environment must still occur but it can be much more flexible.

4.3.4 Environments Building Approach

The FSSA preferred basic environments and interconnections are illustrated in the figure below:

4.3.5 Change Process by Environment

See the change on the following page.

4.3.6 State Responsibilities

4.3.7 Contractor Requirements

4.4 Technical Standards

This section describes the guidelines and technical standards that should govern the development of new software and systems under the Enterprise Medicaid System (EMS). These guidelines and standards are typically what new systems embrace.

These standards relate to:

a. Application Architecture

b. Infrastructure Architecture

c. Web Content Management System

d. Information/Data Architecture Requirements

e. Data Interchange & Common Infrastructure Architecture

4.4.1 Application Architecture

4.4.1.1 Application Architecture Standards

The Contractor shall:

a. Use available Application Architecture assets in constructing solution, unless otherwise specified.

b. Develop and maintain solution design based on SOA.

c. Develop and maintain conceptual system design that includes a definition of business and technical services.

d. Develop and maintain conceptual design that includes a definition of the messages to be used by these services to interact with other services.

e. Design application services as an N-Tier architecture with N greater than or equal to 3. The different tiers must interface with each other and include at a minimum:

1. Database Tier: must include an abstraction layer that separates the application/service tier from the physical database. This abstraction will help future upgrades to underlying databases without significant impact to the rest of the application.

2. Application Tier: must host most of the application logic/business rules for the services.

3. Presentation Tier: must house the User Interface components of the service/application.

f. Design most of the processing in a real-time and interactive fashion.

g. Provide judicious mix of custom developed services and recognized COTS products that could substitute development of certain components.

h. Develop and maintain scalable system design (horizontally or vertically) without having to modify any components, to accommodate growing user and member populations, without performance degradation, by the addition of processing resources.

i. Develop and maintain fault tolerant system design that includes robust error handling capabilities. The application must log all events and all internal parameters when an error occurs so that the error can be debugged properly and a corrective action can be taken.

j. Develop and maintain redundant infrastructure such as server farms and load balancers upon which it will be deployed with automatic failure capabilities.

k. Meet the necessary performance requirements for the State and Contractor in areas such as online transaction response time, batch throughput, resource consumption. Must perform stress testing of the application under normal and peak load conditions to capture performance metrics prior to implementation.

l. Non-programmatically modify and create business rules (rules engine) that are then propagated throughout the data/system. This provides the application with the level of agility needed to sustain it.

m. Standardized Data Exchange. The Contractor’s solution must support State‑standard API and managed file transfer methods to facilitate secure data transmission. The State’s standardized technologies are MuleSoft API Management and GoAnywhere Managed File Transfer (MFT). The Contractor shall utilize these technologies for interfaces unless an exception is approved by IOT and shall align with IOT’s API‑led standards and data‑exchange policies.

n. Develop and maintain server-based application architecture which avoids utilization of thin or thick client topologies, as such, application updates and modifications must be centrally loaded and not require any additional software loaded remotely on each of the clients.

o. Utilize business process modeling technology to maintain all State business processes.

p. Ensure the use of capabilities such as online help screens and tutorials that can decode information using tools such as hover over code.

q. Demonstrate through its design that it is capable of leveraging scalable hardware architecture through the use of good multi-threading techniques; which ensures continued growth over the lifespan of the solution.

4.4.1.2 State Responsibilities

4.4.1.3 Contractor Requirements

4.4.2 Infrastructure Architecture

4.4.2.1 Infrastructure Plan

a. The infrastructure plan must support State‑standard API and managed file transfer methods to facilitate secure data transmission and must support the security access control and authentication solution outlined in Section 4.8, Security

b. The State recognizes that the Contractor may be required to utilize tools that must be coordinated within a single Infrastructure Architecture. The State also recognizes the Contractor will have requirements and preferences for hardware and software that would need to be coordinated in the development of this EMS Infrastructure

c. The Contractor is responsible for the hardware and software and services that are needed to deliver its solution and services and to integrate into the State‑standard API and managed file transfer methods. The Contractor must participate fully in developing, implementing and maintaining a cohesive and workable plan that ensures availability to the solutions and services to support the business operations for the entire Enterprise.

d. The Contractor will provide its own solutions including the integration into the State‑standard API and managed file transfer methods and the maintenance and support of its solution for the duration of the contract. This support should ensure that there is an adequate business process, application and infrastructure monitoring and management in order to fully comply with the availability, performance, and capacity requirements of the PBA project throughout the duration of the Contract and provide auditable reports to support this compliance.

e. The Contractor will share access to its solutions with all other designated vendors, the State and any other authorized users designated by the State at no additional cost to the users. As applicable, vendors should propose and provide sufficient licenses accordingly.

f. The infrastructure includes, but is not limited to, the following tools and software. Citations to SOW sections provide additional details regarding these tools:

Infrastructure Required

Issue Management

Requirements Traceability Matrix

Release Management Software

Security access control and authentication solution

Infrastructure Architecture Standards

Web Management

Service Desk Management System

Communication Management

Content Management

Document Management

Workflow Management

Survey Management

Data Management

Pharmacy Claims Processing and Adjudication System

Any tools necessary to complete Contractor’s scope of work, not otherwise specified above

g. For licensed software required to properly operate and maintain the application or other infrastructure, appropriate licenses must be transferrable to the State, at no cost, and in a manner that does not disrupt operations.

4.4.2.2 Infrastructure Architecture Standards

a. Use available Infrastructure Architecture assets in constructing solution, as appropriate, unless otherwise specified.

b. Negotiate rates for licenses that do not exceed the State’s negotiated Quantity Purchase Agreement (QPA) rates with the software/hardware vendor for existing products that are in State inventory or for new products that are used in the development and operations of the new PBA.

c. Develop and maintain fault tolerant solution that includes the consideration of redundancies for the Production and Disaster recovery environments.

d. Provide plans for regular backup and maintenance schedule for network and server. The Contractor must also specify the tools/techniques for performing this scheduled maintenance of the servers and network equipment. Coordination with IOT staff will be required if the Contractor hosts its application in the IOT data center.

e. Provide 24/7 support for the infrastructure acquired and maintained by them. Any failures in the hosting environments must be attended to immediately. The Contractor shall have a clear escalation procedure through the appropriate chain of command to ensure that the production issue is getting the appropriate attention to meet the level of urgency.

f. Perform regular capacity planning to ensure that proposed infrastructure is sized appropriately for the State workload.

g. Track and report on the capacity and utilization of the infrastructure.

h. Architect software or hardware infrastructure that is put into service for the PBA in such a way to be technically effectively usable from the data center in which it is hosted as well as from within the State’s data center. Flexibility and reuse are high priorities in PBA infrastructure architecture.

4.4.2.3 State Responsibilities

4.4.2.4 Contractor Requirements

4.4.3 Web Content Management

4.4.3.1 Current Web Content Management Overview

The State has standardized various websites across its agencies. Since 2007, the State has published the Web Design Standards document. These standards have since been extended to applications. The primary purpose of these standards was to create a framework to ensure that the “look and feel” for the websites and tools were customer focused, easy-to-use, present consistent information across agencies, and more importantly, reinforce that Indiana’s entities (agencies like FSSA) are part of a larger State government while still allowing the entities to communicate its own messages.

The PBA will also be bound by some of these standards for web design. These web design standards have been based on industry-best practices. In addition to these Web Content Management Standards, additional requirements related to Web Management are presented in Section 5.1 Web Management of this SOW.

a. Use available Web Content Management assets in constructing solution, unless otherwise specified.

b. Adhere to Indiana web design standards for an information-only PBA website hosted by the State on the IN.gov website

c. Use Web Content Technology. The State is an advocate of the use of a content management system to create, maintain, and publish static information on the PBA website. Usage of content management technology reduces programming changes to websites for content modifications and also enforces standards throughout the website.

d. Comply with principles and goals contained in the electronic and information technology accessibility standards adopted by the architectural and transportation barriers compliance board under Section 508 of the Federal Rehabilitation Act of 1973 (29 U.S.C. 794d), as amended.

e. Comply with standards from the Content Management team for the forms that are published to the web for various internal and external uses. These standards include:

1. Publication of forms in Portable Document Format (PDF)

2. Publications must be internally approved by program staff and FSSA forms coordinator

3. Approved forms must be loaded to Forms.IN.gov

f. Use Cascading Style Sheets (CSS) for defining the look and feel of the websites. During creation of CSS, the Contractor must develop global CSS that will enforce consistency across all pages in the website.

g. PBA must be compliant with the latest version and one (1) version older than the latest of the Internet Explorer and the Firefox browsers

h. Must support online help documentation. The online and context sensitive help must allow the users to obtain self-training on how to use the application and receive Medicaid policy information as appropriate.

The referenced web content must at all times be clearly and unambiguously stated, accurate, relevant, and timely. To avoid confusion in the stakeholder community, the Indiana Pharmacy Provider Portal must be accessible through the current Indiana Medicaid website.

4.4.3.2 State Responsibilities

4.4.3.3 Contractor Requirements

4.5 Business Continuity and Disaster Recovery

As the State moves toward higher levels of MITA maturity, the goal is to replace more manual business processes with automated business processes that are completed in a real time environment. The demand will continue to be for systems and solutions that provide instant responses 24 hours a day, 7 days a week.

For this reason, it is imperative that the Contractor place the highest priority on business continuity. Business continuity refers to those activities performed daily to maintain service, consistency and recoverability.

The Contractor is required to develop and maintain its own Business Continuity Plan (BCP) and demonstrate its ability to execute that plan. In addition, the Contractor must collaborate to develop, maintain and execute the integrated BCP.

The Contractor shall establish and maintain a comprehensive service‑tiering model that categorizes all system components and business services according to their criticality and operational impact. The tiering model shall define the maximum tolerable downtime for each tier, not to exceed 24 hours for any tier.

4.5.1 Business Continuity Plan

The Business Continuity Plan (BCP) is created to:

a.…