S-DASOBO-00012374 Attachment I Scope of Work.docx

RFP S-DASOBO-00012374 ALERT Information System (“ALERT IIS”)

ATTACHMENT I - SCOPE OF WORK

Table of Contents

INTRODUCTION

General The Tasks, and associated Services and Deliverables described in this Attachment I, Scope of Work are those anticipated by the State. The anticipated Tasks, Services and Deliverables in this attachment can be used, in context of the RFP, as an approximate expected level of effort for purposes of estimating time and costs.

The State and the successful Proposer will negotiate the Statement of Work for the Contract resulting from this RFP, which will contain the agreed upon Tasks and Deliverables.

Considerations Specific to Program, Agency, and State The successful Proposer will work with the Oregon Health Authority (OHA or Agency) generally, and the Oregon Immunization Program, a program within OHA (OIP or Program) more particularly, to deploy, implement, host and support the Immunization Information System (IIS) Solution. The successful Proposer shall cooperate with Agency’s Independent Quality Management Services (IQMS) and Project Management (PM) team.

The successful Proposer must provide Agency with all documentation and Services for the IIS Solution, and support Agency’s and users’ use of the Solution and Services in accordance with applicable laws, rules, and policies. The successful Proposer must be willing to be onsite for certain Tasks identified in this Scope of Work; Proposer and Agency will discuss and agree during contract negotiations, and periodically through the period of performance under the resulting Contract, on those Tasks (if any) requiring Proposer’s onsite presence.

Proposer must be familiar with the laws, regulations, and policies governing the Services, including restrictions on the location of the performance of the Services (including preparation of Deliverables) and on data transmission and access restrictions. Information on requirements for Services are described in:

1) The RFP,

2) RFP Attachment H, Business Needs/Solution Requirements,

3) RFP Attachment J, Statewide Information Technology (IT) Control Standards, and

4) RFP Attachment A, Sample Contract. See specifically its Section 9, Contractor’s Duties of Confidentiality and Non-Disclosure, and its Exhibit K, Security and Hosting Requirements.

Considerations Specific to Solutions and Tasks, associated Deliverables and Services The successful Proposer shall deliver a proposed Solution that meets Requirements.

Agency anticipates professional consulting, implementation, and operations and maintenance/support Services will be provided by the successful Proposer as part of the Services.

Certain aspects of the Services (and associated Deliverables) under a particular Task may be subject to prior review and authorization by Agency prior to commencement. As negotiated by the parties, prior to beginning work on a specified Deliverable, the successful Proposer shall prepare and deliver to Agency a Deliverable Expectation Document (DED). A DED may include one or more related Deliverables and must include the description of the Deliverable(s), the due date(s) for each of the Deliverable(s), related Acceptance Criteria, and the dates for submission and response. All Deliverables must be formatted in Word, Excel, or PowerPoint and be devoid of marketing type materials, unless another format is agreed in writing.

Following Agency authorization to proceed with the Deliverable(s) described in a DED, successful Proposer shall develop and submit all Deliverables to Agency for review and feedback as set forth in the Contract and in compliance with the Agency-approved DED.

Note that any Deliverable identified as a “plan” is expected to include:

1) All Milestones and Deliverables associated with such Task or sub-Task.

2) All Deliverable submission dates.

3) A schedule detailing, for each of the Milestones and Deliverables, approximate times required to complete each (including estimated amounts of Agency and Contractor staff days shown separately by Task/sub-Task and by role).

Anticipated Tasks and associated Deliverable(s) are described in more detail in Section 3, Anticipated Tasks: Services and Deliverables below.

ANTICIPATED TASKS: SERVICES AND DELIVERABLES

Project Management Objectives and Expectations for Task and Task-related Services and Deliverables The successful Proposer shall provide project management, oversight, and coordination Services. The successful Proposer shall coordinate with Agency (including Program), Agency’s Project Management team, and the IQMS contractor to ensure processes, methods, and artifacts comply with oversight requirements and best practices. The successful Proposer’s Project approach is expected to follow its proven implementation methodology to take advantage of successful implementations demonstrated in other states or sites.

The successful Proposer is responsible for the success of its implementation approach, including the configuration or customization of its proposed Solution, and for cooperatively managing the work of its team and coordinating with State resources. The successful Proposer also is responsible for the operations and maintenance approach.

Examples of project management artifacts the successful Proposer will develop on a continuous basis (through Final Acceptance of the Solution) include project schedules, work breakdown structures, risks/issues reports, testing updates, Go-Live readiness, project control documents, project organizational charts and roles and responsibilities matrices, issue escalation process maps, and process maps.

The successful Proposer will adhere to:

1) Established Oregon Enterprise Information Services (EIS) oversight requirements.

2) Project management standards and best practices for Project Management, specifically, the Project Management Body of Knowledge (PMBOK).

3) Quality standards.

For more information on EIS oversight and the services of the independent iQMS contractor, see:

1) Enterprise Information Services website: IT Investment Oversight (Stage Gate Model) : Project Portfolio Performance: State of Oregon (https://www.oregon.gov/eis/project-portfolio-performance/Pages/it-investment-oversight.aspx)

2) EIS Quality Program website: Enterprise Information Services: Independent Quality Assurance Support & Services: Shared Services: State of Oregon (https://www.oregon.gov/eis/shared-services/Pages/independent-qa-support-and-services.aspx)

3) DAS Statewide, Independent Quality Management Services for Information Technology, Policy and Procedure web links:

a) Policy: 107-004-030.pdf (oregon.gov) (https://www.oregon.gov/das/Policies/107-004-030.pdf)

b) Procedure: 107-004-030_PR.pdf (oregon.gov) (https://www.oregon.gov/das/Policies/107-004-030_PR.pdf)

4) IQMS exhibits web link: eis-ss-iqms-sow-appendix-a-thru-e.pdf (oregon.gov) (v3.1 - 201903) (https://www.oregon.gov/eis/shared-services/Documents/eis-ss-iqms-sow-appendix-a-thru-e.pdf) Deliverables The successful Proposer is expected to prepare and provide:

1) Project Management Plan: Outlines the overall approach for how the Solution implementation project will be governed, executed, monitored, and controlled. Defines the processes and structures for managing key areas such as scope, schedule, budget, risks, resources, communications, change, and quality. The plan serves as the guiding framework that ensures all project activities are aligned, coordinated, and managed consistently from initiation through closeout.

2) Mapping and Gap Analysis: Identifies gaps by comparing the current state of systems, processes, and data flows against the desired future state as defined by Project requirements and objectives. Highlights gaps, redundancies, and areas requiring enhancement or integration. All identified gaps must include actionable recommendations.

3) Project Status Reports: Regular updates on project progress, key accomplishments, upcoming activities, and issues or risks requiring attention. Summarizes current performance against scope, schedule, budget, and resource expectations. Ensures Agency has timely, accurate visibility into project health and decision needs.

4) Business Rules Documentation: Defines the policies, logic, and decision criteria that guide how a system or process must operate. Serves as foundational reference for requirements, system design, testing, and long-term operational use.

5) Requirements Traceability Matrix (RTM): Links each business and technical requirement to its corresponding design, development, and testing artifacts in a concise matrix. Shows whether each Requirement is met, how it is met, and where the supporting evidence is located to provide full visibility into Requirement coverage in support of validation, quality assurance, and future maintenance.

Solution Architecture and Design Objectives and Expectations for Task and Task-related Services and Deliverables The successful Proposer shall design and document architectural-level features for the proposed Solution. Throughout the architectural design work, the successful Proposer will apply Agency’s agreed upon architectural principles, with modularity and extensibility guiding the overall design of the proposed Solution. The successful Proposer shall incorporate these principles across the following dimensions:

1) Functional Modularity: The ability to add, modify, or replace functional features without major rework.

2) Operational Modularity: The ability to support for scalability without adverse impacts to reliability and performance standards.

3) Interoperability Modularity: The ability to integrate with other enterprise systems and external partners via Interfaces (for example, through open standards or APIs).

4) Data Exchange Modularity: The ability to exchange data flexibly in real time and bidirectionally (as applicable), using applicable Interfaces and applicable national standards, including:

a) Exchange of immunization information with external partners (such as immunization providers, healthcare organizations, schools and childcare facilities) using HL7 2.5.1 or HL7 Fast Healthcare Interoperability Resources (FHIR) standards and transfer of immunization information in other formats (such as CSV/flat file or JSON)

b) Exchange of other information (such as immunization provider organizational demographic data, immunization program participation status, or other similar details not directly related to patient health records) with internal or external systems using common interchange standards such as REST/JSON

c) Connectivity with national partners, such as the CDC via CDC IZ Gateway and VTrckS

d) Ad-hoc access for third-party applications and user tools (for example, via representational state transfer (REST) APIs, or direct database connections)

5) Extensibility and Customization: The ability to have extensions and customizations achievable through configuration, declarative customization, and/or modularity.

Deliverables The successful Proposer is expected to prepare and provide:

1) Technical Design Document, which:

a) Summarizes the general principles that guide the successful Proposer’s overall design of the proposed Solution. Principles that influence the proposed Solution design might include, for example, statements about service orientation and loose coupling; Configuration and modularity; and resilience, observability, and fault tolerance.

b) Describes how the proposed Solution’s design aligns with Requirements, including through use of industry‑standard technologies and open frameworks; adoption of cloud‑native services when they provide benefits such as scalability, reliability, or cost efficiency; and an API‑first approach to ensure interoperability across all components of the Solution.

c) Provides overview of the logical architecture of the proposed Solution, including its constituent components, its data flows, its Interfaces and available Integrations, its external dependencies, and its separation of concerns between proposed Solution elements such as end-user interface, control interfaces, services, offline/asynchronous processing, and monitoring/observability services. Includes how design supports high reliability and performance under varying conditions.

d) Describes the hosting services required to deploy the proposed Solution.

e) Gives synopsis of the perimeter access points of the proposed Solution that facilitate integration and data exchange by and between the proposed Solution and other IT systems.

f) Describes how the proposed Solution can be modified or extended, including through configuration, modular add-on components, or code-based development when necessary. This description must explain how user interfaces, reports, data exchange methods , APIs, and business or process logic may be adjusted, enhanced, or expanded using the tools and methods available within the Solution.

g) Provides overview of the architectural-level design features that support ongoing operations, including backup/recovery, disaster recovery, monitoring and alerting, and automated performance fault corrections.

2) Identity and Access Management Methodology: Documents how the proposed Solution facilitates authentication, authorization, and identity provisioning, including integration with Agency’s enterprise-level Microsoft Active Directory and Entra ID infrastructure.

3) Security and Privacy Compliance Description: Describes how the proposed architectural-level design complies with State and Agency policies, and associated IT control standards, regarding information asset security and privacy applicable to PII that comprises “Level 3, Restricted” information assets (“Level 3, Restricted” is defined in EIS Information Asset Classification Policy found at https://www.oregon.gov/das/Policies/107-004-050.pdf).

4) Data Architecture Summary: Summarizes data models used for storage and transport and data storage methods for the proposed Solution.

5) Functional Specification Design: Documents functional specifications that describe how the proposed Solution will meet business and user Requirements. Documentation shall include detailed business rules, end-to-end business process flows, descriptions of user interactions, and user interface screen mockups or wireframes. Documentation may additionally include use cases or user stories that define expected system behavior and support subsequent design, development, and testing activities.

6) Solution Component and Customization Report: Describes all proposed Solution components and their roles within the overall architecture, including dependencies, integration points, and interoperability mechanisms. The report shall identify all configuration and customization capabilities of the proposed Solution, describe the tools and methods used to perform each type of configuration or customization, and explain how these capabilities support modularity, extensibility, maintainability, and alignment with Agency requirements.

Solution Components, Customization, and Deployment Objectives and Expectations for Task and Task-related Services and Deliverables The successful Proposer is expected to deploy a proposed Solution that is flexible, configurable, and customizable to meet functional and non-functional requirements per both national standards (i.e., CDC IIS Functional Standards) and local or Agency requirements. The successful Proposer shall carry out the activities documented in the Accepted Deliverables for this Task.

Deliverables The successful Proposer is expected to prepare and provide:

Solution Deployment Plan: Describes methodology for deploying changes to proposed Solution infrastructure, configuration, and functionality during implementation and throughout Operations & Maintenance, including:

0. How this methodology supports deployments that minimize cost and operational impacts while maintaining proposed Solution reliability and security

0. Tooling to be used for development and operations control, such as code version control, fault monitoring, build and deployment pipeline processes, and deployment approvals and confirmations Solution Architecture, Components, Customization, and Security Specification: Documents the complete technical composition of the proposed Solution, including:

c. Components

d. Dependencies

e. Integration points Required configurations and customizations

f. Security and perimeter control measures

g. Performance and load‑balancing approaches

h. Licensing

i. Support and maintenance requirements

j. Any design and functional elements and associated benefits related to loose coupling This Deliverable must clearly identify configuration versus customization, describe the tools and methods used for each, and include diagrams or written summaries sufficient to provide the State with a full understanding of how the proposed Solution is structured, secured, and meets Requirements.

Data Conversion and Migration Objectives and Expectations for Task and Task-related Services and Deliverables The successful Proposer shall ensure that all Agency Data from multiple legacy systems is successfully analyzed, cleaned, transformed, migrated, and validated in the proposed Solution in a manner that is complete, accurate, transparent, and repeatable. The objectives of this Task include:

1. Meeting defined data quality thresholds. Migrated Agency Data must achieve a minimum data quality standard of at least 99 percent accuracy and 99 percent completeness, measured using Agency‑approved validation rules.

a. Accuracy means the percentage of migrated data values that match the corresponding values in the authoritative legacy source systems, as verified through field‑level comparison.

b. Completeness means the percentage of required data elements from the legacy source systems that are successfully migrated into the proposed Solution.

The specific formulas, required data elements, sampling methods (if any), and validation procedures used to calculate accuracy and completeness will be defined in the Data Conversion and Migration Plan and must be approved by Agency before Extract, Transform, and Load (ETL) activities begin.

2. Ensuring transparency and repeatability. All steps, tools, code, data mappings, transformation rules, and validation methods used during ETL must be fully accessible to Agency and documented in sufficient detail to allow Agency to repeat or reproduce ETL processes as needed.

3. Supporting thorough testing and validation. The successful Proposer must provide Agency full visibility into intermediate and final ETL results, including any findings, errors, or issues detected through profiling, testing, or validation activities.

4. Providing all necessary ETL services. The successful Proposer shall provide all ETL‑related Services—whether performed directly or through subcontractors—that are required to meet the data migration objectives, subject to consultation and direction from Agency.

Data Migration The successful Proposer is expected to:

1) Analyze source system data formats and integrity from multiple legacy systems whose data will be migrated into the single proposed Solution or archived into a database, including correcting and/or reformatting as necessary or as instructed by Agency

2) Perform data conversion activities, including preparation and planning, analysis and design, conversion build, conversion testing, mock conversions, conversion cutover, and support

3) Allow Agency to:

a) Have transparent and complete access or visibility into all steps in the data conversion processes, including as to all tools, code, Configuration, documentation, and data products used by the successful Proposer during the ETL processes or necessary to successfully complete all ETL processes

b) Inspect intermediate and final results Convert/Migrate Agency Data from multiple legacy systems to proposed Solution and Validate The successful Proposer is expected to:

1) Convert: Perform analysis, profiling and cleaning of legacy Agency Data, to include all activities (and related Services) that are necessary or reasonably desirable in connection with legacy data cleanup efforts

2) Migrate: Perform migration (or archival) of all relevant legacy Agency Data, including documents, to the proposed Solution or archive database, to include:

a) During data migration planning activities, working in consultation with Agency to verify all Agency Data to be migrated

b) Performing ETL processes on Agency Data from multiple source legacy systems to the proposed Solution

c) Converting and loading Agency Data into the proposed Solution

d) Performing end-to-end validation of the conversion and loading processes, with the successful Proposer performing the initial and ongoing Agency Data loads during data migration, in consultation with Agency and Agency’s Project team

3) Validate: Test and validate the quality of the migrated Agency Data per Section 3.9, Testing, below, and identify and make improvements in its proposed Solution functionality to ensure Agency Data integrity Deliverables The successful Proposer is expected to prepare and provide:

1) Data Conversion and Migration Plan: Describes planned ETL activities such as mapping, gap and other analysis, profiling, cleaning, formatting, extracting, transforming, loading, etc. Describes all Services and tools that Proposer determines, after analysis of source systems and in consultation with Agency, will be needed to complete ETL activities consistent with the objectives for this data conversion and migration Task as to all data migrated from multiple legacy systems to the proposed Solution.

2) Solution Database Documentation: Provides design of database architecture required for the target Environment with enough detail to support data integrity, performance, and scalability while meeting applicable Requirements. Key components include logical and physical data models, data migration mapping (including source-to-target mapping for all data elements and transformation rules for data cleansing and standardization), performance and security considerations, and backup and recovery plans. Must also include supporting metadata for the proposed Solution, including an entity relationship diagram and data dictionary.

3) Data Conversion and Migration Completion Report: Summarizes the full results of the ETL and migration effort, confirming that legacy Agency Data from all source systems has been analyzed, cleaned, converted, migrated, and validated in the proposed Solution with at least 99 percent accuracy and completeness. Documents the repeatable processes, tools, test results, data quality findings, and final approvals demonstrating that the migration objectives have been met.

Infrastructure The successful Proposer shall provide, configure, and support all infrastructure necessary to host, operate, and maintain the proposed Solution in alignment with Agency requirements and the State’s cloud‑forward policies.

Objectives and Expectations for Task and Task-related Services and Deliverables Cloud Structure Agency prefers a proposed Solution and its associated deployment framework that offers an efficient structuring of resources in the target cloud subscription space for encompassing the entire set of Solution multiple use contexts, as described in the Requirements and in Section 3.5.1.3, Multiple Use Context, below, by using or combining strategies such as:

1) On-demand/ephemeral environments

2) Time-sliced/rotated environments

3) Environment profiles

4) Multi-tenancy/shared service layer(s)

5) Auto-scaling/burst-control Scalability The proposed Solution and its associated deployment framework must be able to scale to quickly accommodate changing demands for Solution-provided Services. These changes may include:

1) Increasing data exchange traffic and/or end users

2) Meeting the multiple use context requirement (as further described in Section 3.5.1.3, Multiple Use Context, below)

3) Adapting to changes in applicable law, regulation, policy or ordinance

4) Other unforeseen factors Multiple Use Context The proposed Solution and its deployment framework must support multiple, concurrently available environments that enable Agency to carry out essential activities—including production operations, testing, training, onboarding of integrations, and other temporary or special-use needs—without disrupting production services. The purpose of this requirement is to ensure that Agency can safely validate changes, train users, and support partner integrations while maintaining system stability and data protection.

At a minimum, the proposed Solution must provide distinct environments dedicated to:

1) Training: for delivering end‑user and train‑the‑trainer instruction as described in Section 3.8, Organizational Change Management (OCM) and Section 3.10, Training.

2) Quality Assurance: for ongoing testing, Acceptance activities, Enhancements, configurations, and customizations.

3) Onboarding of Integrations: for testing and troubleshooting interfaces with partner systems before they connect to production.

Each environment must implement appropriate safeguards that prevent unauthorized access to real‑world protected data, such as use of de‑identified or masked data sets, mock data, or other suitable controls. Boundaries between environments must be designed to ensure that protected data cannot traverse into non‑production environments except where expressly authorized and consistent with the Accepted System Security Plan. Environments must remain consistent with all requirements in Section 3.14, Hosting and Solution Security.

Deliverables The successful Proposer is expected to prepare and provide:

1) Solution Infrastructure and Environment Plan: Describes the target cloud architecture, integrations with existing Agency infrastructure, environment profiles (Prod, QA, Training, Integration-Onboarding Environments), scaling policies, and data protection boundaries for the proposed Solution; as well as strategies related to development and implementation.

2) Infrastructure Operational Readiness & Sign‑Off Report: Confirms delivery and validation of the infrastructure and all required use contexts. Includes evidence of performance/scalability tests, security/privacy validation against the Accepted System Security Plan, monitoring/alerting dashboards in place, and final approvals and residual risks/issues with owners and dates.

Integrations and Interfaces Objectives and Expectations for Task and Task-related Services and Deliverables The proposed Solution must support the exchange of data between itself and Agency partners in a way that’s flexible and adaptable, demonstrates high performance, and is responsive to future needs (i.e. the evolution of data exchange standards, client technologies, and security and privacy). The proposed Solution must have a flexible, open approach to providing Integrations for itself based on a modern integration strategy. It must support a modern, enterprise-wide integration strategy for Agency and for the proposed Solution.

Building Integrations shall be the responsibility of the successful Proposer but must be done in coordination and cooperation with Agency’s staff, Agency’s third-party contractors, and other vendors.

Minimally, by Go-Live the proposed Solution is expected to:

1) Leverage an integration strategy that seeks to meet the specific needs of external and Agency Interested Parties,

2) Integrate with all IT systems connected to the legacy ALERT IIS and support data exchanges, without interruption of the proposed Solution-provided Services, and on various levels utilizing various Interfaces,

3) Provide quantifiable, measurable, near real-time or real-time data transfer (Integration) between the proposed Solution and each Agency partner’s IT systems,

4) Support and have implemented all Interfaces (including APIs), as documented in the Integrations and Interfaces Plan, and carry associated Interface (including APIs) Documentation as provided by the successful Proposer,

5) Access the source database via:

a) Current industry standard APIs, including flat files, database backups, and original data exchange files

b) A direct connection to the source database to independently run SQL queries against the source database, and

6) Allow for its rapid Configuration by Proposer-trained Agency staff to quickly provide future Integrations with respect to the proposed Solution as they are identified and defined.

The proposed Solution is expected to include at a minimum all Integrations (and associated Interfaces) that are present in the legacy ALERT IIS. Agency’s legacy ALERT IIS currently maintains unidirectional and/or bidirectional secure data exchanges with many partner IT systems, including provider Electronic Health Records (EHRs), Vital Records, VTrckS, and CDC IZ Gateway (see Figure 1, below). Each of these partner IT systems is an Integration with respect to Agency’s legacy ALERT IIS; the technical mechanism whereby each of these Integrations and Agency’s legacy ALERT IIS can maintain unidirectional and/or bidirectional secure data exchanges is an Interface.

Figure 1 The Current State Context Diagram represents how the ALERT IIS interfaces with other IT systems. Arrows between the IIS and the other IT systems represent interfaces and communication by and between each system.

Proposer’s Integration and Interface Services (and associated Deliverables) must include, at a minimum, the following combinations of Interface and respective IT systems (each of which becomes a successful Integration with respect to the proposed Solution upon successful Interface creation by the Solution-provided Services):

1) Web services interface for standard HL7 immunization messaging in real time

2) Direct connection end-point for immunization providers and other authorized organizations to send/receive immunization data

3) Connection to the CDC IZ Gateway to send/receive immunization data with federal partners and other jurisdictional IISs

4) Real-time connection to other Agency IT systems, e.g. POST-PMI, that is two-way even if only one-way is actively used

5) Ability to add additional connections to other API services, as prioritized by Agency (for example, if CDC develops an API for vaccine management to their VTrckS system)

6) Ad-hoc data access for other third-party applications and/or end-user data access tools, via methods such as RESTful APIs, direct database connections, etc.

Additionally, all Integrations and Interfaces must support future updates to adapt with evolving and new national standards, e.g. FHIR.

Deliverables The successful Proposer is expected to prepare and provide:

1) Integrations and Interfaces Plan: Documents clear, structured view of how the proposed Solution will connect, communicate, and exchange Agency Data with all partner IT systems. Describes how the proposed Solution will support Oregonians in accessing their own immunization records (and those for which they are authorized proxy access) in the proposed Solution via a Public Portal (as a user interface). It must also include a plan for how Interfaces will be tested, reported on, and improved.

2) Interfaces and Interface Control Documentation: Gives concise, governed description of each proposed Solution Interface and the Public Portal—its purpose, data, technical requirements, controls, and operational expectations—to ensure consistent understanding, maintenance, and change management. Includes data validations and business rules, error handling, interface design for each Interface (for example, batch versus real-time, API specification, interface formats), data mapping, and transformations.

3) Integrations and Interfaces Completion Report: Provides brief, governed summary confirming that all planned proposed Solution Integrations and Interfaces (including the Public Portal) have been delivered, tested, validated, and transitioned into operations with any remaining risks, issues, or follow-up actions clearly documented.

Digital Accessibility (DA) Objectives and Expectations for Task and Task-related Services and Deliverables Objectives of the successful Proposer’s Services and Deliverables, and proposed Solution, under this digital accessibility Task include advancing Agency’s commitment to providing:

1) Equitable access to information and services, and

2) Effective communications that are culturally and linguistically appropriate and accessible for people who have different communications needs or abilities.

To this end, the successful Proposer shall deliver Services and Deliverables that meet applicable standards for digital accessibility established in ODHS/OHA Operational Policy ODHSOHA 010-030 (Digital Accessibility in Hardware, Software and Systems) (found online at https://sharedsystems.dhsoha.state.or.us/DHSForms/Served/me010-030.pdf) and ODHSOHA 010-029 (Digital Accessibility in Content Creation and Sharing) (found online at https://sharedsystems.dhsoha.state.or.us/DHSForms/Served/me010-029.pdf). The proposed Solution and each Deliverable must meet all applicable standards for digital accessibility. Applicable standards are those set-in law, administrative rule, and the ODHS/OHA operational policies, including as those laws, administrative rules, and policies are updated from time to time. Digital spaces and content that must meet digital accessibility applicable standards include the proposed Solution, the proposed Solution’s components, and any digital documentation (such as built‑in features, client portals, training materials, user guides, electronic documents, multimedia content, and any web, desktop, or mobile applications included in any of the Deliverables) that will be available to State staff or the public, and any other digital content to be delivered under the Contract resulting from this RFP.

Deliverables The successful Proposer is expected to prepare and provide:

1) Digital Accessibility Compliance Plan: Identifies specific applicable standards with which the successful Proposer’s Deliverables currently complies, will comply, and how the successful Proposer will ensure and report on compliance.

2) Accessibility Conformance Reports (ACR): An ACR must be included with each digital Deliverable submitted for Agency review; if one is not available or is more than 12 months old, state so and provide any contextual information successful Proposer believes will support Agency’s ability to evaluate the associated Deliverable. The ACR is expected to be based on the latest version of the Web Content Accessibility Guidelines (WCAG) Voluntary Product Accessibility Template (VPAT®) that evaluates conformance of the proposed Solution and Proposer-provided digital content with WCAG 2.2 level A and AA success criteria. The ACR is expected to:

a) Be no more than 12 months old at the time of submission to Agency,

b) Accurately reflect the current state of accessibility of the ACR-referenced Deliverable(s),

c) Be specific to the Deliverable(s) (and version(s)) proposed by successful Proposer for review and identifications of deficiencies,

d) Be completed by qualified personnel knowledgeable in digital accessibility and the proposed Deliverable(s),

e) Be provided in an accessible format,

f) If Proposer is proposing a SaaS Solution, cover core application functionality, authentication, and onboarding flows, help documentation, and any third-party components or integrations with which users will interact. If mobile or responsive access is common, include those experiences. Define that scope explicitly, and document what's excluded to avoid procurement follow-up questions, and

g) Include a proposed remediation plan that specifically addresses mitigation measures Proposer will take prior to remediation of any deficiencies if identified.

3) Digital Accessibility Compliance Report: Reports on the proposed Solution, any constituent SaaS thereof, and all other digital Deliverables each meet digital accessibility applicable standards. Summarizes the results of accessibility evaluations (including the ACR), identifies any accessibility issues found, and explains how those issues will be remediated, and mitigated prior to remediation.

Organizational Change Management (OCM) Objectives and Expectations for Task and Task-related Services and Deliverables OCM’s objective is to ensure successful adoption of the Accepted proposed Solution. OCM addresses both how the organization will change and how individuals within Agency, partner organizations, and the public will transition through the stages of awareness, desire, knowledge, ability, and reinforcement (ADKAR). The successful Proposer shall provide comprehensive OCM Services as documented in the Deliverables for this Task and aligned with the Prosci® methodology (or an equivalent structured framework).

Deliverables The successful Proposer is expected to prepare and provide:

1) OCM Plan: Outlines of how the successful Proposer will prepare, support, and guide people through changes introduced by implementing the proposed Solution. Its purpose is to help users adopt new systems, processes, or technologies smoothly, with minimal disruption and will define what is changing and why (the case for change), who is impacted and how their work will be affected, how communication will occur to keep stakeholders informed and engaged, training and readiness activities to ensure users know how to work in the new environment, support mechanisms during and after go‑live, and strategies to manage resistance and reinforce adoption over time. The OCM plan must identify roles and responsibilities to execute OCM and must additionally include:

a) Communications Strategy and Plan:

i) Describes a well-developed, tailored communication plan that ensures timely, transparent, and consistent messaging across all Interested Parties.

ii) Covers communications planning and execution for pre-Go-Live and O&M phases.

iii) Includes key messages, communication channels, frequency, and feedback mechanisms.

iv) Proposes how the successful Proposer’s team will work with OHA to collaborate on communications strategy, schedule, artifacts, and related activities.

b) Interested-Party Mapping and Engagement:

i) Identifies and categorizes Interested Parties based on influence, impact, and readiness.

ii) Develops targeted engagement strategies to address resistance, to build sponsorship, and to foster advocacy.

iii) Provides Interested Parties analysis reports and engagement tracking tools.

c) Training: Documents how training Deliverables and Services provided under Section 3.10, Training will be integrated within the OCM program.

d) Workflow Mapping, Gap Analysis and Impact Assessment and Process Alignment:

i) Describes future-state workflows aligned with the proposed Solution’s functions and associated processes.

ii) Leverages legacy ALERT IIS workflows, as documented by OHA, to analyze gaps with respect to workflows from legacy to proposed Solution, identifying redundancies and recommending opportunities for optimization.

iii) Includes associated impact assessment report(s) in transitioning to the proposed Solution.

iv) Includes process documentation and transition guides to support adoption of the proposed Solution.

e) Benefits Management Validation Report:

i) Delineates clear benefits to all Interested Parties (including end users and OHA) for this change from the current IIS to the proposed Solution (and the successful Proposer shall consult with OHA in delineating these benefits).

ii) Indicates how the proposed Solution will deliver these benefits and over what time frame, from Go-Live through the Stabilization Period.

f) Communications Materials: Provides for ongoing templates and artifacts (such as newsletters, FAQs, executive talking points) necessary to execute against the Communications Plan.

Testing Objectives and Expectations for Task and Task-related Services and Deliverables.

The successful Proposer shall comprehensively test the proposed Solution to validate its functionality. Additionally, the successful Proposer will perform integration testing with interfacing and impacted IT systems, including Interfaces with internal Agency IT systems and external IT systems operated by partners and associated Integrations.

The successful Proposer will perform Testing Services in accordance with the Accepted Testing Services Plan. The employment of both manual testing and use of industry-standard automated testing software is strongly encouraged.

Testing Types and Expected Data The types of testing Agency would expect the successful Proposer to run include:

1) Unit

2) Regression

3) System integration

4) Functional (end-to-end)

5) Integration

6) Interface

7) User acceptance

8) Pilot

9) Security and penetration

10) Performance and load

11) Stability

12) Smoke Each test is expected to include:

1) Marking as to the test suite(s) (such as pilot, implementation, data migration, data validation) with which it is (they are) associated,

2) Metadata such as a test ID, links or references to specific business requirement, security control, and detailed requirement statements that it tests,

3) Links to execution instructions (test scripts) and what user role executes the test, and

4) Test suites and groups shall exercise all conditions including:

a) Positive tests (i.e., the tested behavior should succeed)

b) Negative tests (i.e., the tested behavior should fail or escape)

c) Boundary tests (i.e., using test data where values are near, on, or past a boundary or limit)

d) Accessibility tests (i.e., verify functionality meets accessibility guidelines).

The proposed Solution needs separate testing done in accordance with the above applicable types of testing and minimum inclusions for tests for (a) system testing, and (b) data validation testing.

Prior to User Acceptance Testing (UAT), the proposed Solution is expected to be flexible in handling changes and meeting the Requirements of this RFP. Regression testing is expected to fully test all previously implemented Solution functionality.

Third Party Penetration Testing The successful Proposer shall ensure an independent third party performs and reports directly to Agency on penetration testing of the proposed Solution prior to implementation and after any significant change made to the proposed Solution (or any of its constituent components). Penetration testing is expected to be performed by an independent third party on at least an annual basis; the State expects such testing when additions or changes to functionality impact the security framework or architecture of the proposed Solution, or when a new vulnerability with respect to the proposed Solution (or any of its constituent components) is identified.

User Acceptance Testing (UAT) The successful Proposer shall support UAT. UAT is the final testing performed by Agency after functional, QA, and regression testing are completed. The successful Proposer is expected to pre-populate look-up values and other reference data into the testing Environment.

Deliverables The successful Proposer is expected to prepare and provide:

1) Testing Plan and Defect Tracking Mechanism: Identifies the approach and activities required for full testing of the proposed Solution prior to Go-Live. Each applicable test must be identified in the Testing Plan. Additionally, the Testing Plan should include a Defect Tracking Mechanism, which could be a spreadsheet or automated tracking method as agreed to through collaboration between Agency and successful Proposer.

2) UAT testing Environment that:

a) Is a “production like” Environment,

b) Is visibly distinguishable from production, development, and other Environments used,

c) Includes software release number and description of changes in release (release notes),

d) Accepts software release cycles, where release number/name are prominently displayed,

e) Is maintained and updated to support effective UAT,

f) Contains only data that has been de-identified and stripped of personally identifiable or sensitive information, and

g) Is pre-populated with look-up values and other reference data.

3) Testing and Defect Tracking Report(s): Delivered following key testing activities in the format as agreed upon for the Defect Tracking Mechanism, such reports provide traceability to test cases/scripts and allow effective management of the bug/fix cycle. Reports shall include results of tests, including those supported by the successful Proposer and those done by a third party, and be reported to Agency in a timely manner. Each Defect Tracking Report should identify Defects and vulnerabilities, highlighting those that are critical, and make recommendations for appropriately resolving or mitigating them.

Training Objectives and Expectations for Task and Task-related Services and Deliverables The successful Proposer shall deliver a Training Plan and program, including from pre-Go-Live through Final Acceptance, that:

1) Empowers Agency staff trainers to train external Interested Parties (including clinical, school and childcare users who are not members of the general public) to utilize the proposed Solution as intended,

2) Provides Agency staff with the operational and technical knowledge they need to use the proposed Solution in their specific roles,

3) Leverages pre- and post-training assessments to measure learning outcomes,

4) Enables a member of the general public to utilize the Public Portal as intended, and

5) Uses feedback and performance data for continuous improvement.

This comprehensive training must continue for the duration of the anticipated Contract. It will include initial instruction prior to Go-Live, refresher courses and updates for new features of the proposed Solution for new Agency staff, advanced training post Go-Live, and ongoing knowledge transfer to sustain operational continuity by Agency staff of the proposed Solution (including its related Public Portal).

This ongoing knowledge transfer comprises knowledge transfer Services to Agency staff, including supporting Agency experience in design, programming, testing, and operations, as well as ad hoc training throughout the Contract consistent with Agency staff roles and responsibilities for operations, maintenance (as needed) and support of the proposed Solution (including its related Public Portal).

Training Groups and Audiences The training program must have tailored learning journeys for key program areas, as agreed upon by Agency and successful Proposer. The following is a representative list:

1) Agency Staff Trainers

2) Help Desk

3) Data Exchange

4) School Law

5) Immunization Quality Improvement Program (IQIP)

6) IIS Technical

7) System Administrators

8) General Agency Staff

9) Consumer / General Public (Agency will be responsible for the training plan that Agency staff trainers will use to educate clinical, school and childcare users of the proposed Solution.)

Training Methods The successful Proposer’s training methods may include:

1) Online self-paced training modules to provide basic system exposure and instruction

2) Instructor-led, classroom-based, hands-on training at multiple sites

3) Instructor-led online training

4) Self-directed, just-in-time training such as job aids and task-based instructional video clips

5) Built-in support such as embedded help and mouse overs

6) Knowledge repository and tool tips relevant to the information displayed on the current page

7) Practice time and scripts in a dedicated training environment Deliverables The successful Proposer is expected to prepare and provide:

1) Training Plan and Schedule for Delivery to End Users (including the Train-The-Trainer Plan incorporated therein), which achieves the following:

a) Documents objectives for the training program and a plan to train Agency staff (including trainers) and the public, in complement to the Agency’s plan. The train-the-trainer component of the Training Plan shall be delivered at least twelve (12) months prior to Go-Live.

b) Defines respective roles, responsibilities, and coordination mechanisms between Proposer staff, Agency staff, and stakeholders. Examples of responsibilities that should be documented in the Training Plan include the development and maintenance of training materials, coordination of training development and delivery, support for internal trainers to sustain post-implementation learning activities, and documentation and reporting on training completion and outcomes.

c) Provides a schedule for delivering training to end users leading up to Go-Live and during Operations & Maintenance.

d) Describes how training will be delivered, tracked toward completion by individual user, and reported on via dashboards or reports (for example, by using a vendor-provided Learning Management System (LMS) or similar).

e) Outlines a plan for evaluating the training program’s effectiveness and how such evaluations will be leveraged for continuous improvement.

2) Training Materials: Support end-user mastery of the proposed Solution, from pre-Go-Live through Final Acceptance. Materials may be deployed via vendor LMS or similar, or via Public Portal, as appropriate. They must be updated per Section 3.16, Solution Documentation and Updates, and as part of ongoing activities under Section 3.13, Operations, Maintenance, Support, and Service Levels. Materials include:

a) For staff: Training content,…