6060-0 final na~1.pdf

RFI S-44300-00012106 (OHA#6060)

DAS Procurement Services, Version 4.0 – March 25, 2018 Page 1 of 26

STATE OF OREGON

COVER PAGE

Oregon Health Authority, is issuing this Request for Information(RFI) under

OregonBuys # S-44300-00012106 – OHA #6060 for Medicaid Enterprise Systems

System Integration

Date of Issue and Time: November 21, 2024

Opening Date and Time: January 16, 2025, 4:00 PM

Single Point of Contact (SPC): Nancy Alameda , IT Procurement Manager

Address: 500 Summer Street NE E-03 City, State, Zip Salem, OR 97301 Phone (voice) 971-374-3509 Email: nancy.i.alameda@odhsoha.oregon.gov

You can get this document in other languages, large print, braille, or a format you prefer free of charge. Contact the Contract Administrator at the contact information found below. We accept all relay calls.

mailto:nancy.i.alameda@odhsoha.oregon.gov

DAS Procurement Services, Version 4.0 – March 25, 2018 Page 2 of 26

Table of Contents

SECTION 1: GENERAL

INFORMATION

1.1 INTRODUCTION

1.2 BACKGROUND

1.3 REQUEST FOR INFORMATION PURPOSE

1.4 WHO MAY RESPOND?

1.5 PROJECT OVERVIEW

1.6 DUE DATE 6

1.7 SINGLE POINT OF CONTACT (SPC)

SECTION 2: SCOPE OF

WORK 7

2.1 SCOPE 7

SECTION 3: SUBMISSION AND RESPONSE REQUIREMENTS13

3.1 SUBMISSION REQUIREMENTS

3.2 OWNERSHIP/PERMISSION TO USE MATERIALS

3.3 QUESTIONS / REQUESTS FOR CLARIFICATION

DAS Procurement Services, Version 4.0 – March 25, 2018 Page 3 of 26

SECTION 1: GENERAL INFORMATION

1.1 INTRODUCTION

The State of Oregon, acting by and through its Oregon Health Authority (“OHA” or “Agency”) is seeking information from qualitified vendors regarding the enhancement and integration of the Agency’s Medicaid Enterprise System (MES).

OHA’s goal is to modernize and streamline the existing systems to improve efficiency, data accessibility, and service delivery to beneficiaries. This Request for Information (RFI) aims to gather insights and innovative solutions to identify system integration services and a system integration platform that will enable OHA to build a robust, interoperable, and scalable MES that meets the current and future needs of our Medicaid program.

The purpose of thisRFI is to help inform OHA in the development of their requirements and will help OHA develop future procurement strategies. The Agency is examining the possibility of releasing a Request for Proposal (“RFP”) at a later date.

This RFI will not result in any kind of contract or Agreement, nor will obligate the Agency to procure goods or services of any kind. The information gained in this RFI may be used by the Agency to gain an understanding from current industry experts in order to help develop a future competitive selection process that could result in a contract. Agency is not responsible for any expenses or costs incurred by any Respondent in submitting a Response to this RFI. Each Respondent does so solely at the Respondent’s own expense. All costs incurred in preparing and submitting a Response will be the responsibility of the Respondent and will not be reimbursed by Agency.

1.2 BACKGROUND

OHA is Oregon’s State Medicaid agency responsible for ensuring access to health services are available to Oregonians. Oregon Department of Human Serices (ODHS) is the agency responsible for administering other public assistance benefits and also provides operational support for distinct Medicaid functions. The partnership between OHA and ODHS and their alignment with business operations and technology services unites these two agencies in their common goal to establish streamlined Medicaid eligibility, improve access to care and service delivery, and expand coverage to more Oregonians.

Agency supports the technology needs for all ODHS and OHA programs:

• 16,580 OHA and DHS agency staff in 166 local offices and facilities around the State,

• 250 applications related to eligibility, enrollment, benefit issuance, licensing, protective services, public health, case management, hospital management, provider payments and many more health and human services needs. While many applications are new and supported, many non-MMIS applications are dated, with a variety of platforms, programming languages, databases and interfaces,

• 300+ technology tools and support applications, DAS Procurement Services, Version 4.0 – March 25, 2018 Page 4 of 26

• 25,700+ technology devices (computers, printers, servers, mobile devices).

Agency intends to create an enterprise vision for transforming the way Medicaid services and programs are delivered to Oregon citizens, going beyond technology. This encompasses a re-evaluation of processes and organization structures used to manage and deliver program services, efforts to work across organizational boundaries to more effectively manage and deliver health and human services (HHS) in Oregon, and transition from current operating models to an outcomes-based focus.

The goal of the Oregon Medicaid Enterprise Systems Modernization program (MES Mod) is to move away from a monolithic system to a modular Medicaid IT environment that facilitates efficient administration of the Medicaid program. A modular approach will enable the Agency to design and conduct a sequenced procurement and deployment of an end-to-end MES solution, prioritizing the implementation of modules based on business needs.

A Modernized Medicaid IT environment offers many benefits to Agency, such as the ability to adapt to changes in state and federal policies, new programs and initiatives, and technological advancements in a timely and cost-effective manner. It will also promote innovation and allow the Agency to focus on “best-in-class” interoperable solutions.

Recent CMS guidance on modernization and re-use provided via State Medicaid Director Letters requires states to follow a modular approach supporting the timely and cost-effective delivery of IT projects. https://www.medicaid.gov/federal-policy-guidance/downloads/smd16010.pdf. CMS has broadcast an intent to support projects which address rational, discrete subsets of Medicaid Enterprise functionality that are interoperable with other parts of the Medicaid enterprise. States are required to follow these modularity principles in their development of new or replacement Medicaid Management Information System (MMIS) components.

OHA’s MMIS was implemented in 2008 and since its implementation, the MMIS has undergone significant changes in response to monumental shifts within the overall landscape of healthcare delivery in the United States. These changes have included passage of the Affordable Care Act at the federal level; establishment of Oregon’s Coordinated Care Organization (CCO) model; Cover All Kids; and Healthier Oregon Program. The State’s MMIS system currently resides and is supported in the State’s data center and efforts are currently underway to move the MMIS from on premise location to a secure cloud platform and expect the move to be completedend of 4th quarter 2025.

1.3 REQUEST FOR INFORMATION PURPOSE

Agency has initiated this RFI to gather information from the market for System Integration services providers with experience or skill in modernizing Medicaid systems--with specific interest in those with experience modernizing and modularizing Medicaid Management Information Systems (MMISs) and associated applications. Participation in this RFI will assist https://www.medicaid.gov/federal-policy-guidance/downloads/smd16010.pdf https://www.medicaid.gov/federal-policy-guidance/downloads/smd16010.pdf

DAS Procurement Services, Version 4.0 – March 25, 2018 Page 5 of 26 the State of Oregon in creating an RFP which provides more detailed scope elements that align with market availability and successful outcomes from other state efforts.

The following table is an example of systems and interfaces the State has identified associated with the MES ecosystem, however this is not a complete list. A current full list of impacted systems and interfaces is still in discovery phase and the Agency will likely need further assistance with assessment work by a selected SI services provider.

1.4 WHO MAY RESPOND?

Agency is seeking information from Respondents who have demonstrated experience in successfully completing System Integration work for other states Medicaid Modernization programs.

1.5 PROJECT OVERVIEW

The Agency is seeking information on Integration Services and Integration Platform (IS/IP) services for the purpose of eventually procuringthese integration services and an infrastructure needed to integrate existing systems and introduce new modules into the MES. Integration offers greater functionality and capability over the current data exchange process. Through increased flexibility and interoperability, the Agency will advance as it moves beyond simple data interfaces between two points.

The foundational infrastructure of System Integration Services and Integration Platform (IS/IP) is critical to building an architecture framework aligned with the core principle that business processes inform and drive the implementation of business, information, and technical services.

The Agency’s preference is to engage an IS/IP vendor to provide integration services, facilitating centralized management and monitoring of modules. The Agency anticipates an IS/IP vendor will establish and maintain interoperability using an integration platform that enables secure real-time, or near real-time, data exchange and integration of data and services across systems.

IS/IP vendor services are also anticipated to include the provision of integration platform software and architecture to perform connectivity, security, communication, and processing to translate protocols, platforms, and data formats facilitating data sharing and the reuse of processing services.

The Agency is seeking an integration platform to enable a common information exchange process to eliminate point-to-point communication between individual systems. If a new module needs to be added or replaced to meet business needs, the architectural model will promote sharing information and services across the enterprise using common semantics, syntax and mechanisms to communicate through the integration platform and fundamental infrastructure components. All business logic associated with interacting across the enterprise will be routed and managed by the integration platform to integrate services across disparate systems and allow services and technology to remain independent.

Successful implementation of the integration platform along with integration of business and

DAS Procurement Services, Version 4.0 – March 25, 2018 Page 6 of 26 technical services from various functional areas in the Medicaid enterprise is expected to lead to improved services and support further modular development.

The following table represents an example of some of the known MES related systems and interfaces that would be impacted as part of system integration services outlined in this RFI.

This should be viewed as a snapshot/example as the entire OR state MES Ecosystem is under review and likely full discovery and inventory would be work the State may seek from a selected SI Provider.

1.6 DUE DATE

Responses to this RFI will be received until the Opening date and time as referenced on the cover page of this RFI. Responses received after the Opening date and time shall be deemed late and will not be considered.

1.7 SINGLE POINT OF CONTACT (SPC)

The SPC for this RFI is identified on the Cover Page, along with the SPC’s contact information. Respondent shall direct all communications related to any provision of the RFI only to the SPC, whether about the technical requirements of the RFI, the RFI process, or any other provision.

AUTHORITY AND METHOD

Agency has authority and is using the Request for Information solicitation method, pursuant to ORS 279A.050.

DAS Procurement Services, Version 4.0 – March 25, 2018 Page 7 of 26

SECTION 2: SCOPE OF WORK

2.1 SCOPE

Agency is seeking information for the following scope elements to inform an anticipated Request for Proposals for IS/IP services and technology. Estimated time and cost elements can be entered into Attachment C-2.

2.1.1 Integration Roadmap (if available, please provide an example addressing the following)

2.1.1.1 Which integration points do you typically recommend a state pursue first?

2.1.1.2 What were the average deployment timelines for these modules?

2.1.1.3 Is there an integration roadmap structure that you’ve seen lead to the most successful outcomes?

2.1.1.4 What do you typically see in regard to content and structure for a integration roadmap?

2.1.1.5 What approach was used to break down larger systems into basic building blocks that allow for customizations?

2.1.1.6 What level of involvement did your firm have in the creation and successful rollout of an integration roadmap?

2.1.2 Initial Infrastructure Assessment

2.1.2.1 Data Mapping

2.1.2.1.1 What were your steps for completing data mapping for other states?

2.1.2.1.2 What documentation do you need to complete your data mapping work?

2.1.2.1.3 What was the extent of your data mapping?

2.1.2.1.4 What is a rough estimate on the cost and timeline to complete data mapping?

2.1.2.2 Interface Mapping

2.1.2.2.1 What were your steps for completing interface mapping for other states?

2.1.2.2.2 What documentation do you need to complete your interface mapping work?

DAS Procurement Services, Version 4.0 – March 25, 2018 Page 8 of 26

2.1.2.2.3 What was the extent of your interface mapping?

2.1.2.2.4 What is a rough estimate on the cost and timeline to complete interface mapping?

2.1.3 Gap Analysis

2.1.3.1 What was the process you used with others states to create a Gap Analysis (ex.

additional information gathering etc)?

2.1.3.2 What were the elements of the analysis (ex. planning and steps to move from current to future state)?

2.1.3.3 What is a rough estimate on the cost and timeline for completing a Gap Analysis?

2.1.4 Technical Reference Architecture (TRA) Review

2.1.4.1 Please provide your process for analysis of an existing state TRA and how you go about suggesting updates to the document.

2.1.4.1.1 How does your Gap Analysis and Infrastructure Assessment figure into the TRA analysis and update suggestions for this document?

2.1.4.1.1.1 What variables would need to be considered for making that decision?

2.1.4.1.1.2 Which document ownership structure have you seen work best on other statewide efforts?

2.1.5 Techncal Architecture Roadmap

2.1.5.1 Have you created a technical architecture roadmap in preparation for a platform integration in other states?

2.1.5.1.1 What did the roadmap include?

2.1.5.1.2 What information did you need to complete the roadmap?

2.1.5.1.3 What is a rough estimate for the cost and time to create this document?

2.1.6 To Be Infrastructure Plan

2.1.6.1 What do you typically include in a To-Be Infrastructure Plan?

2.1.6.2 What is a rough estimate for cost and time to create this document?

2.1.7 System Integration Platform Design and Set Up

2.1.7.1 When entering an engagement, how do you identify in-place opportunities for

DAS Procurement Services, Version 4.0 – March 25, 2018 Page 9 of 26

Medicaid integrations. How are these improvements captured as part of your initial design?

2.1.7.2 What do you consider to be the key functions and roles that should be provided by a SI vendor related to platform design and set-up?

2.1.7.3 What is the typical timeframe for completing a platform design?

2.1.7.4 What are the native technical and functional options that come with the COTS (non-customized) version of your SI platform?

2.1.7.4.1 What is the full range SI functionality your platform can provide across all SDLC phases?

2.1.7.5 What is the rough estimate for cost to set up the platform once a design is approved?

2.1.7.6 What is the typical timeline for initial platform set up?

2.1.7.7 After platform set up, what is the rough estimate for cost on maintenance and hosting of your platform?

2.1.7.7.1 Is there an option to have the state manage the platform? If yes, which states that you’ve worked with have done this?

2.1.7.8 What are the typical change management procedures that you use for platform maintenance, the integration of new interfaces, platform upgrades and new Leverage Technical Services?

2.1.8 Ongoing Support

2.1.8.1 What ongoing support has your firm provided for maintaining and updating the platform and integrated systems?

2.1.8.2 Have you provided additional support to states beyond platform operations and maintenance? If so, what kind of additional support was provided?

2.1.9 Are any Leverage Technical Services (platform tools) included as part of your System Integration Platform?

2.1.9.1 Does your platform include Single Sign On (SSO – Azure AD) – What is the high level pricing and functional capabilities associated with your SSO solution?

2.1.9.2 Does your solution include Identity Management components such as OAuth, SAML and OpenID compatibility?

2.1.9.2.1 Does your Solution include any capability to establish a Common Oregon ID as part fo a Master Data Management Solution?

DAS Procurement Services, Version 4.0 – March 25, 2018 Page 10 of 26

2.1.9.2.1.1 If so, what is a rough estimation on the cost and time needed to set up that functionality?

2.1.9.3 Does your solution include the ability to integrate with existing Electronic Document Management System (EDMS)?

2.1.9.3.1 Oregon uses Laserfiche and Kofax as it’s primary EDMS Systems, is your platform compatible with these software suites?

2.1.9.3.2 What is the rough estimation of cost and time needed to integrate the above referenced tools into your platform?

2.1.9.3.3 If integration is not possible, what is the rough estimation of cost and time needed to convert to your EDMS tool?

2.1.9.4 What other Leveraged Technical Services do you recommend Oregon consider including in an initial platform implementation? Why?

2.1.10 Master Integration Plan (if available, please provide example)

2.1.10.1 What are the components of the plan you would provide?

2.1.10.2 As related to adding/integrating a new (non-SI) module, what is the rough estimation of cost and time needed to integrate a new module into your SI framework/ platform?

2.1.10.3 What information would you need to complete this plan?

2.1.10.4 How often does the plan typically get updated?

2.1.10.5 Who typically updates the plan? Agency? Vendor?

2.1.10.6 How do you ensure interoperability between different modules or components in an integrated system?

2.1.10.7 How do you handle integration of legacy systems with newer modular components?

2.1.10.8 How do you manage dependencies between different modules in a system?

2.1.11 Test Strategy and Plans

2.1.11.1 Test Strategy

2.1.11.1.1 What overall end-to-end test strategy do you typically recommend for a MES type of implementation?

DAS Procurement Services, Version 4.0 – March 25, 2018 Page 11 of 26

2.1.11.1.2 What module integration test strategy do you typically use for testing?

2.1.11.1.3 How do you approach testing and quality assurance for individual integrated modules vs the integrated system as a whole?

2.1.11.2 Test Plan

2.1.11.2.1 Has your company created Test Plans for other states MMIS modernization programs?

2.1.11.2.1.1 If so, what information and Agency support was needed to create the test plans?

2.1.11.2.1.2 Who maintained the plans once they were created and adapted them to additional functionality?

2.1.11.2.1.3 Does your company recommend to or manage multi-vendor integrated test plans?

2.1.11.2.1.4 How much automated testing is typically employed when testing?

2.1.12 Organizational Change Management

2.1.12.1 Has your firm provided Organizational Change Management (OCM) services in support of MES modernization efforts at other states? If so, what type of OCM services did you provide?

2.1.13 Additional Requirements

2.1.13.1 The Respondent should describe how a successful systems integrator performs the following:

2.1.13.1.1 How would the respondant integrate multiple MES and non-MES systems using open and published interfaces utilizing industry standards when appropriate in a hybrid cloud based and on-premesis environment.

2.1.13.1.2 How would the respondant support multiple versions of the same interface.

2.1.13.1.3 How would the respondent support synchronous and asynchronous communications.

2.1.13.1.4 How would the respondant display and report health all system interfaces that have been integrated into their platform.

2.1.13.1.5 How would the respondant work with all module vendors through each phase of a new module life cycle from planning to maintenance and

DAS Procurement Services, Version 4.0 – March 25, 2018 Page 12 of 26 future enhancements.

2.1.13.1.6 How would the respondant participate in design sessions for other MES modules to ensure proper interface design.

2.1.13.2 The Respondent should describe an understanding of the work, and the potential estimated:

2.1.13.2.1 Timeframe to complete the project.

2.1.13.2.2 Describe the number of vendor employees and support structure including estimated number and type of state personnel needed to support vendor efforts

2.1.13.2.3 Other pertinent information.

2.1.13.2.4 Describe qualifications related to this RFI for all employees potentially assigned to the project and specify the management support structure.

2.1.14 Data related questions

2.1.14.1 What approaches have you taken to interface with data warehouses or operational data stores and how is this unique to the Systems Integrator role?

2.1.14.2 What is your experience coordinating the exchange of data between system components, data warehouses or operational data stores when that data is subject to different security levels or conditions?

2.1.14.3 What is your experience creating system context diagrams to capture data sources and subscribers from existing data warehouses or operational data stores, and new data sources that arise?

2.1.14.4 What approaches have you taken to ensure that custodial metadata from disparate data sources is maintained across interfaces?

2.1.14.5 As a Systems Integrator, what role have you played in Data Governance structures?

2.1.14.6 What approaches have you taken to successfully operate complex data and system architectures in a federated manner? What styles of architectures have you utilized (e.g. Data Lake, Data Mesh, etc.)?

DAS Procurement Services, Version 4.0 – March 25, 2018 Page 13 of 26

SECTION 3: SUBMISSION AND RESPONSE REQUIREMENTS

3.1 SUBMISSION REQUIREMENTS

OregonBuys Electronic Response. Respondent must submit its Response electronically through OregonBuys. Respondent must follow the procedures outlined in detailed instructions on how to submit an Response can be found at OregonBuys Vendor Formal Solicitation Response.

Respondents to this RFI must upload the following files in pdf format:

• Attachment A – Respondent Information and Certification Sheet

• Attachment B – Disclosure Exemption Affidavit

• Attachment C-1 - Copy and Paste of Questions in Section 2.1 including Respondent’s responses

• Attachment C-2 – Estimated cost sheet (optional)

In addition, Respondents are encouraged to provide the following items (preferably in its entirety) and upload as a .pdf file for each in Oregon Buys.

• A sample high-level Project Implementation Plan.

• A sample Cost Estimate that includes items noted above in section 2.1 and to include:

a. Data Mapping

b. Gap Analysis

c. Technical Architecture Roadmap

d. To-Be Infrastructure Plan

e. Design-approved SI Plantform Setup

f. Ongoing Maintenance & Hosting of Platform

g. Other costs SI Platform

h. Module Integration, and

i. software, training, maintenance, services, and any other requirements for the project.

Please include potential cost-saving measures (without compromising quality).

3.2 OWNERSHIP/PERMISSION TO USE MATERIALS

All Responses are public record and are subject to public inspection. Application of the Oregon Public Records Law will determine whether any information is actually exempt from disclosure.

https://www.oregon.gov/das/ORBuys/Documents/OregonBuys%20Vendor%20Formal%20Solicitation%20Response.pdf

DAS Procurement Services, Version 4.0 – March 25, 2018 Page 14 of 26

All Responses submitted to this RFI become the property of Agency. By submitting a Response to this RFI, Respondent grants the State of Oregon a non-exclusive, perpetual, irrevocable, royalty-free license for the rights to copy, distribute, display, prepare derivative works of and transmit the Response solely for the purpose of reviewing the Response, or as otherwise needed to administer the RFI process, and to fulfill obligations under Oregon Public Records Law (ORS 192.410 through 192.505). Responses, including supporting materials, will not be returned to Respondent.

If Respondent believes any of its Response is exempt from disclosure under Oregon Public Records Law (ORS 192.311 through 192.478), Respondent shall complete and submit the Disclosure Exemption Affidavit (Attachment B) and Respondent also shall submit a fully redacted version of its Response, clearly identified as the redacted version.

3.3 QUESTIONS / REQUESTS FOR CLARIFICATION

All inquiries, whether relating to the RFI process, administration, deadline, the intent or technical aspects of the RFI must:

• Be delivered to the SPC via an OregonBuys submission or email;

• Reference the OregonBuys bid number;

• Identify Respondent’s name and contact information;

• Refer to the specific area of the RFI being questioned (i.e. page, section and paragraph number); and

• Be received by at December 18, 2024 4:00 PM PST.

DAS Procurement Services, Version 4.0 – March 25, 2018 Page 15 of 26

ATTACHMENT A — RESPONDENT INFORMATION AND

CERTIFICATION SHEET

Legal Name of Responden (as filed with the IRS):

Address: City, State, Zip:

State of Incorporation: Entity Type:

Contact Name: Telephone: Email:

Oregon Business Registry Number (if required):

Any individual signing below hereby certifies they are an authorized representative of Respondent and that:

1. No attempt has been made or will be made by the Respondent to induce any other person or organization to submit or not submit a Response.

2. All contents of this Respondent Information and Certification Sheet are truthful and accurate and have been prepared independently from all other Responses, and without collusion, fraud, or other dishonesty.

3. Respondent acknowledges that the Response for any of the services described in this RFI will be used for planning and informational purposes only. Agency may issue a separate procurement in the future or directly negotiate for the services required by Agency.

Authorized Signature Date

(Printed Name and Title)

*** THIS PAGE SHOULD BE THE COVER PAGE OF THE RESPONSE ***

DAS Procurement Services, Version 4.0 – March 25, 2018 Page 16 of 26

ATTACHMENT B — DISCLOSURE EXEMPTION AFFIDAVIT

____________________ (Affiant), being first duly sworn under oath, and representing [insert Proposer Name] (hereafter “Proposer”), hereby deposes and swears or affirms under penalty of perjury that:

12. I am an employee of the Proposer, I have knowledge of the Request for Proposals referenced herein, and I have full authority from the Proposer to submit this affidavit and accept the responsibilities stated herein.

13. I am aware that the Proposer has submitted a Proposal, dated on or about [insert date] (the “Proposal”), to the State of Oregon (State) in response to Request for Proposals [insert RFP #], for [insert description of RFP], and I am familiar with the contents of the RFP and Proposal.

14. I have read and am familiar with the provisions of Oregon’s Public Records Law, Oregon Revised Statutes (“ORS”) 192.311 through 192.478, and the Uniform Trade Secrets Act as adopted by the State of Oregon, which is set forth in ORS 646.461 through ORS 646.475. I understand that the Proposal is a public record held by a public body and is subject to disclosure under the Oregon Public Records Law unless specifically exempt from disclosure under that law.

15. I have reviewed the information contained in the Proposal. The Proposer believes the information listed in Exhibit A is exempt from public disclosure (collectively, the “Exempt Information”), which is incorporated herein by this reference. It is my opinion that the Exempt Information is exempt from disclosure under Oregon’s Public Records Law under the specifically designated sections as set forth in Exhibit A or constitutes “Trade Secrets” under either the Oregon Public Records Law or the Uniform Trade Secrets Act as adopted in Oregon because that information is either:

A. A formula, plan, pattern, process, tool, mechanism, compound, procedure, production data, or compilation of information that:

i. is not patented,

ii. is known only to certain individuals within the Proposer’s organization and that is used in a business the Proposer conducts,

iii. has actual or potential commercial value, and

iv. gives its user an opportunity to obtain a business advantage over competitors who do not know or use it.

or

B. Information, including a drawing, cost data, customer list, formula, pattern, compilation, program, device, method, technique or process that:

DAS Procurement Services, Version 4.0 – March 25, 2018 Page 17 of 26

i. Derives independent economic value, actual or potential, from not being generally known to the public or to other persons who can obtain economic value from its disclosure or use; and

ii. Is the subject of efforts by the Proposer that are reasonable under the circumstances to maintain its secrecy.

16. I understand that disclosure of the information referenced in Exhibit A may depend on official or judicial determinations made in accordance with the Public Records Law.

Affiant’s Signature

State of ___________)

) ss:

County of ________)

Signed and sworn to before me on ___________ (date) by ______________________ (Affiant’s name).

Notary Public for the State of _________________

My Commission Expires: _________

RFI – OB # S-44300-00012056 OHA #6060

DAS Procurement Services, Version 4.5 March 31, 2023 Page 18 of 26

EXHIBIT A TO ATTACHMENT B

Proposer identifies the following information as exempt from public disclosure under the following designated exemption(s):

DAS Procurement Services, Version 4.5 March 31, 2023 Page 19 of 26

ATTACHMENT C-1

RFP# S-44300-00012056 (OHA #6060)

Section 2: Scope of Work

Questions/Respondent’s Responses

Agency is seeking information for the following scope elements to inform an anticipated Request for Proposals for IS/IP services and technology.

Respondent: Please provide as complete answers to following questions taken from Section 2: Scope of Work as possible. Note: the requested estimated time and cost can be entered into Attachment C-2.

We realize this is a broad set of questions. If you have samples of deliverables or other documentation that would help to answer some of the following questions in lieu of answering line by line please feel free to include with your response. Thank you.

From Section 2.1:

2.1.1. Integration Roadmap (if available, please provide an example addressing the following)

• Which integration points do you typically recommend a state pursue first?

• What were the average deployment timelines for these modules?

• Is there an integration roadmap structure that you’ve seen lead to the most successful outcomes?

• What do you typically see in regard to content and structure for a integration roadmap?

• What approach was used to break down larger systems into basic building blocks that allow for customizations?

• What level of involvement did your firm have in the creation and successful rollout of an integration roadmap?

2.1.2 Initial Infrastructure Assessment

• Data Mapping o What were your steps for completing data mapping for other states?

o What documentation do you need to complete your data mapping work?

o What was the extent of your data mapping?

o What is a rough estimate on the cost and timeline to complete data mapping?

• Interface Mapping

DAS Procurement Services, Version 4.5 March 31, 2023 Page 20 of 26 o What were your steps for completing interface mapping for other states?

o What documentation do you need to complete your interface mapping work?

o What was the extent of your interface mapping?

o What is a rough estimate on the cost and timeline to complete interface mapping?

2.1.3 Gap Analysis

• What was the process you used with others states to create a Gap Analysis (ex. additional information gathering etc)?

• What were the elements of the analysis (ex. planning and steps to move from current to future state)?

• What is a rough estimate on the cost and timeline for completing a Gap Analysis?

2.1.4 Technical Reference Architecture (TRA) Review

• Please provide your process for analysis of an existing state TRA and how you go about suggesting updates to the document.

• How does your Gap Analysis and Infrastructure Assessment figure into the TRA analysis and update suggestions for this document?

• What variables would need to be considered for making that decision?

• Which document ownership structure have you seen work best on other statewide efforts?

2.1.5 Techncal Architecture Roadmap

• Have you created a technical architecture roadmap in preparation for a platform integration in other states?

• What did the roadmap include?

• What information did you need to complete the roadmap?

• What is a rough estimate for the cost and time to create this document?

2.1.6 To Be Infrastructure Plan

2.1.6.1 What do you typically include in a To-Be Infrastructure Plan?

2.1.6.2 What is a rough estimate for cost and time to create this document?

2.1.7 System Integration Platform Design and Set Up

DAS Procurement Services, Version 4.5 March 31, 2023 Page 21 of 26

• When entering an engagement, how do you identify in-place opportunities for Medicaid integrations. How are these improvements captured as part of your initial design?

• What do you consider to be the key functions and roles that should be provided by a SI vendor related to platform design and set-up?

• What is the typical timeframe for completing a platform design?

• What are the native technical and functional options that come with the COTS (non-customized) version of your SI platform?

• What is the full range SI functionality your platform can provide across all SDLC phases?

• What is the rough estimate for cost to set up the platform once a design is approved?

• What is the typical timeline for initial platform set up?

• After platform set up, what is the rough estimate for cost on maintenance and hosting of your platform?

• Is there an option to have the state manage the platform? If yes, which states that you’ve worked with have done this?

• What are the typical change management procedures that you use for platform maintenance, the integration of new interfaces, platform upgrades and new Leverage Technical Services?

2.1.8 Ongoing Support

• What ongoing support has your firm provided for maintaining and updating the platform and integrated systems?

• Have you provided additional support to states beyond platform operations and maintenance? If so, what kind of additional support was provided?

2.1.9 Are any Leverage Technical Services (platform tools) included as part of your System Integration Platform?

• Does your platform include Single Sign On (SSO – Azure AD) – What is the high level pricing and functional capabilities associated with your SSO solution?

• Does your solution include Identity Management components such as OAuth, SAML and OpenID compatibility?

• Does your Solution include any capability to establish a Common Oregon ID as part fo a Master Data Management Solution?

o If so, what is a rough estimation on the cost and time needed to set up that functionality?

DAS Procurement Services, Version 4.5 March 31, 2023 Page 22 of 26

• Does your solution include the ability to integrate with existing Electronic Document Management System (EDMS)?

• Oregon uses Laserfiche and Kofax as it’s primary EDMS Systems, is your platform compatible with these software suites?

• What is the rough estimation of cost and time needed to integrate the above referenced tools into your platform?

• If integration is not possible, what is the rough estimation of cost and time needed to convert to your EDMS tool?

• What other Leveraged Technical Services do you recommend Oregon consider including in an initial platform implementation? Why?

2.1.10 Master Integration Plan (please include example if possible)

• What are the components of the plan you would provide?

• As related to adding/integrating a new (non-SI) module, what is the rough estimation of cost and time needed to integrate a new module into your SI framework/ platform?

• What information would you need to complete this plan?

• How often does the plan typically get updated?

• Who typically updates the plan? Agency? Vendor?

• How do you ensure interoperability between different modules or components in an integrated system?

• How do you handle integration of legacy systems with newer modular components?

• How do you manage dependencies between different modules in a system?

2.1.11 Test Strategy and Plans

Test Strategy

• What overall end-to-end test strategy do you typically recommend for a MES type of implementation?

• What module integration test strategy do you typically use for testing?

• How do you approach testing and quality assurance for individual integrated modules vs the integrated system as a whole?

Test Plan

• Has your company created Test Plans for other states MMIS modernization programs?

DAS Procurement Services, Version 4.5 March 31, 2023 Page 23 of 26

• If so, what information and Agency support was needed to create the test plans?

• Who maintained the plans once they were created and adapted them to additional functionality?

• Does your company recommend to or manage multi-vendor integrated test plans?

• How much automated testing is typically employed when testing?

2.1.12 Organizational Change Management

Has your firm provided Organizational Change Management (OCM) services in support of MES modernization efforts at other states? If so, what type of OCM services did you provide?

2.1.13 Additional Requirements

The Respondent should describe how a successful systems integrator performs the following:

• How would the respondant integrate multiple MES and non-MES systems using open and published interfaces utilizing industry standards when appropriate in a hybrid cloud based and on-premesis environment.

• How would the respondant support multiple versions of the same interface.

• How would the respondantsupport synchronous and asynchronous communications.

• How would the respondant display and report health all system interfaces that have been integrated into their platform.

• How would the respondant work with all module vendors through each phase of a new module life cycle from planning to maintenance and future enhancements.

• How would the respondant participate in design sessions for other MES modules to

DAS Procurement Services, Version 4.5 March 31, 2023 Page 24 of 26 ensure proper interface design.

The Respondent should describe an understanding of the work, and the potential estimated:

• Timeframe to complete the project.

• Describe the number of vendor employees and support structure including estimated number and type of state personnel needed to support vendor efforts.

• Other pertinent information.

• Describe qualifications related to this RFI for all employees potentially assigned to the project and specify the management support structure.

2.1.14 Data related questions

• What approaches have you taken to interface with data warehouses or operational data stores and how is this unique to the Systems Integrator role?

• What is your experience coordinating the exchange of data between system components, data warehouses or operational data stores when that data is subject to different security levels or conditions?

• What is your experience creating system context diagrams to capture data sources and subscribers from existing data warehouses or operational data stores, and new data sources that arise?

• What approaches have you taken to ensure that custodial metadata from disparate data sources is maintained across interfaces?

DAS Procurement Services, Version 4.5 March 31, 2023 Page 25 of 26

• As a Systems Integrator, what role have you played in Data Governance structures?

• What approaches have you taken to successfully operate complex data and system architectures in a federated manner? What styles of architectures have you utilized (e.g.

Data Lake, Data Mesh, etc.

DAS Procurement Services, Version 4.5 March 31, 2023 Page 26 of 26

Attachment C-2

Esimated Cost Example – RFI OB#S-44300-00012056 (OHA 6060)

Respondent: You may include estimated cost in a separate document on your own form or using this form

Task / Deliverable Labor Category (if applicable)

Estimated Number of

Hours Estimated Price

Estimated Price to complete all tasks and deliverables listed: