2024-1600-0249-1624-020 RFP - National Electronic Disease Surveillance System.pdf

STATE OF ALASKA

REQUEST FOR PROPOSALS

OFFERORS ARE NOT REQUIRED TO RETURN THIS FORM.

IMPORTANT NOTICE: IF YOU RECEIVED THIS SOLICITATION FROM THE STATE OF ALASKA’S “ONLINE PUBLIC NOTICE”

WEB SITE, YOU MUST REGISTER WITH THE PROCUREMENT OFFICER LISTED IN THIS DOCUMENT TO RECEIVE

NOTIFICATION OF SUBSEQUENT AMENDMENTS. FAILURE TO CONTACT THE PROCUREMENT OFFICER MAY RESULT

IN THE REJECTION OF YOUR OFFER.

ISSUED BY:

DEPARTMENT OF HEALTH

DIVISION OF PUBLIC HEALTH

PRIMARY CONTACT:

ANNELIESE ZLITNI

PROCUREMENT OFFICER

anneliese.zlitni@alaska.gov

STATE OF ALASKA NATIONAL ELECTRONIC DISEASE

SURVEILLANCE SYSTEM BASE SYSTEM (NBS) INTERFACE,

APPLICATION, AND DEVELOPMENT SUPPORT

RFP 2024-1600-0249/1624-020

ISSUED OCTOBER 17, 2024

THE STATE OF ALASKA, DEPARTMENT OF HEALTH, DIVISION OF PUBLIC HEALTH, SECTION OF EPIDEMIOLOGY IS SOLICITING PROPOSALS FOR INTERFACE, APPLICATION, AND DEVELOPMENT SUPPORT, WITH POSSIBLE

MIGRATION SUPPORT, AND POSSIBLE HOSTING AND RELATED SERVICES, FOR THE ALASKA VERSION OF THE CENTERS FOR DISEASE CONTROL AND PREVENTION’S NATIONAL ELECTRONIC DISEASE SURVEILLANCE SYSTEM

BASE SYSTEM.

TABLE OF CONTENTS

SECTION 1. INTRODUCTION & INSTRUCTIONS

SEC. 1.01 PURPOSE OF THE RFP

SEC. 1.02 BUDGET

SEC. 1.03 DEADLINE FOR RECEIPT OF PROPOSALS

SEC. 1.04 MANDATORY REQUIREMENTS

SEC. 1.05 REQUIRED REVIEW

SEC. 1.06 QUESTIONS PRIOR TO DEADLINE FOR RECEIPT OF PROPOSALS

SEC. 1.07 RETURN INSTRUCTIONS

SEC. 1.08 ASSISTANCE TO OFFERORS WITH A DISABILITY

SEC. 1.09 AMENDMENTS TO PROPOSALS

SEC. 1.10 AMENDMENTS TO THE RFP

SEC. 1.11 RFP SCHEDULE

SEC. 1.12 ALTERNATE PROPOSALS

SEC. 1.13 NEWS RELEASES

SECTION 2. BACKGROUND INFORMATION

SEC. 2.01 BACKGROUND INFORMATION

SECTION 3. SCOPE OF WORK & CONTRACT INFORMATION

SEC. 3.01 GOALS AND OBJECTIVES

SEC. 3.02 SCOPE OF WORK

SEC. 3.03 DELIVERABLES

A. INTERFACE SUPPORT (DELIVERABLE 1)

B. APPLICATION SUPPORT (DELIVERABLE 2)

C. ALASKA-SPECIFIC INFRASTRUCTURE SUPPORT (DELIVERABLE 3)

D. MIGRATION (DELIVERABLE 4)

E. HOSTING INFRASTRUCTURE AND PLATFORM MANAGEMENT (DELIVERABLE 5)

SEC. 3.04 HIPAA SECURITY ASSESSMENT REQUIREMENTS

SEC. 3.05 INTENT TO PROPOSE AND NON-DISCLOSURE AGREEEMENT

SEC. 3.06 HIPAA AND HITECH INFORMATION SECURITY AGREEMENT (ISA)

SEC. 3.07 INFORMATION TECHNOLOGY (IT) RELATED CONTRACTUAL REQUIREMENTS

SEC. 3.08 CONTRACT TERM AND WORK SCHEDULE

SEC. 3.09 CONTRACT TYPE

SEC. 3.10 PAYMENT PROCEDURES

SEC. 3.11 CONTRACT PAYMENT

SEC. 3.12 LOCATION OF WORK

SEC. 3.13 SUBCONTRACTORS

SEC. 3.14 JOINT VENTURES

SEC. 3.15 RIGHT TO INSPECT PLACE OF BUSINESS

SEC. 3.16 F.O.B. POINT

SEC. 3.17 CONTRACT PERSONNEL

SEC. 3.18 INSPECTION & MODIFICATION - REIMBURSEMENT FOR UNACCEPTABLE DELIVERABLES

SEC. 3.19 CONTRACT CHANGES - UNANTICIPATED AMENDMENTS

SEC. 3.20 NONDISCLOSURE AND CONFIDENTIALITY

SEC. 3.21 INDEMNIFICATION

SEC. 3.22 INSURANCE REQUIREMENTS

SEC. 3.23 TERMINATION FOR DEFAULT

SECTION 4. PROPOSAL FORMAT AND CONTENT

SEC. 4.01 RFP SUBMITTAL FORMS

SEC. 4.02 SPECIAL FORMATTING REQUIREMENTS

SEC. 4.03 OFFEROR INFORMATION AND CERTIFICATIONS (SUBMITTAL FORM A)

SEC. 4.04 EXPERIENCE AND QUALIFICATIONS (SUBMITTAL FORM B)

SEC. 4.05 UNDERSTANDING OF THE PROJECT (SUBMITTAL FORM C)

SEC. 4.06 METHODOLOGY USED FOR THE PROJECT (SUBMITTAL FORM D)

SEC. 4.07 MANAGEMENT PLAN FOR THE PROJECT (SUBMITTAL FORM E)

SEC. 4.08 MANDATORY REQUIREMENTS (SUBMITTAL FORM F)

SEC. 4.09 SUBCONTRACTORS (SUBMITTAL FORM G)

SEC. 4.10 IT CONTRACTUAL REQUIREMENTS – SAAS SOLUTIONS (SUBMITTAL FORM H)

SEC. 4.11 COST PROPOSAL (SUBMITTAL FORM I)

SEC. 4.12 INTENT TO PROPOSE AND NON-DISCLOSURE AGREEMENT ............................... ERROR! BOOKMARK NOT DEFINED.

SECTION 5. EVALUATION CRITERIA AND CONTRACTOR SELECTION

SEC. 5.01 SUMMARY OF EVALUATION PROCESS

SEC. 5.02 EVALUATION CRITERIA

SEC. 5.03 SCORING METHOD AND CALCULATION

SEC. 5.04 EXPERIENCE AND QUALIFICATIONS (20%)

SEC. 5.05 UNDERSTANDING OF THE PROJECT (15%)

SEC. 5.06 METHODOLOGY USED FOR THE PROJECT (10%)

SEC. 5.07 MANAGEMENT PLAN FOR THE PROJECT (15%)

SEC. 5.08 CONTRACT COST (COST PROPOSAL)

SEC. 5.09 APPLICATION OF PREFERENCES

SEC. 5.10 ALASKA BIDDER PREFERENCE

SEC. 5.11 ALASKA VETERAN PREFERENCE

SEC. 5.12 ALASKA MILITARY SKILLS PROGRAM PREFERENCE

SEC. 5.13 ALASKA OFFEROR PREFERENCE

SEC. 5.14 COST REASONABLENESS

SEC. 5.15 CONTRACT NEGOTIATIONS

SEC. 5.16 OFFEROR NOTIFICATION OF SELECTION

SECTION 6. GENERAL PROCESS AND LEGAL INFORMATION

SEC. 6.01 INFORMAL DEBRIEFING

SEC. 6.02 ALASKA BUSINESS LICENSE AND OTHER REQUIRED LICENSES

SEC. 6.03 STANDARD CONTRACT PROVISIONS

SEC. 6.04 BUSINESS ASSOCIATE AGREEMENT (BAA)

SEC. 6.05 QUALIFIED OFFERORS

SEC. 6.06 PROPOSAL AS PART OF THE CONTRACT

SEC. 6.07 ADDITIONAL TERMS AND CONDITIONS

SEC. 6.08 HUMAN TRAFFICKING

SEC. 6.09 RIGHT OF REJECTION

SEC. 6.10 STATE NOT RESPONSIBLE FOR PREPARATION COSTS

SEC. 6.11 DISCLOSURE OF PROPOSAL CONTENTS

SEC. 6.12 ASSIGNMENT

SEC. 6.13 DISPUTES

SEC. 6.14 SEVERABILITY

SEC. 6.15 SUPPLEMENTAL TERMS AND CONDITIONS

SEC. 6.16 SOLICITATION ADVERTISING

SEC. 6.17 SITE INSPECTION

SEC. 6.18 CLARIFICATION OF OFFERS

SEC. 6.19 DISCUSSIONS WITH OFFERORS

SEC. 6.20 FEDERALLY IMPOSED TARIFFS

SEC. 6.21 PROTEST

SECTION 7. ATTACHMENTS

SEC. 7.01 ATTACHMENTS

SECTION 1. INTRODUCTION & INSTRUCTIONS

SEC. 1.01 PURPOSE OF THE RFP

The State of Alaska (SOA) Department of Health (DOH), Division of Public Health (DPH), Section of Epidemiology (SOE) is soliciting proposals from qualified offerors for supporting the implementation of NBS 7.x in a compatible cloud environment. Requested support services fall under the areas of National Electronic Disease Surveillance System (NEDSS) Base System (NBS) interface support, NBS application support, and Alaska-specific application development, with optional service areas that include migration assistance (cloud-to-cloud) and related hosting services.

SEC. 1.02 BUDGET

The DOH, DPH, SOE estimates a budget of between $3,000,000.00 and $4,000,000.00 for completion of this project. Proposals priced at more than $4,000,000.00 will be considered non-responsive.

Payment for the contract is subject to funds already appropriated and identified.

SEC. 1.03 DEADLINE FOR RECEIPT OF PROPOSALS

Proposals must be received no later than 2:00 P.M. prevailing Alaska Time on Friday, January 17, 2025. Late proposals or amendments will be disqualified and not opened or accepted for evaluation.

SEC. 1.04 MANDATORY REQUIREMENTS

To be considered responsive for this RFP, an offeror must meet the mandatory minimum experience requirements that are provided in Submittal Form F – Mandatory Requirements. Failure to meet all these requirements will result in immediate disqualification.

SEC. 1.05 REQUIRED REVIEW

Offerors should carefully review this solicitation for defects and questionable or objectionable material.

Comments concerning defects and questionable or objectionable material should be made in writing and received by the procurement officer at least ten (10) days before the deadline for receipt of proposals. This will allow time for the issuance of any necessary amendments. It will also help prevent the opening of a defective proposal and exposure of offeror's proposals upon which award could not be made.

SEC. 1.06 QUESTIONS PRIOR TO DEADLINE FOR RECEIPT OF PROPOSALS

All questions must be in writing and directed to the procurement officer and least ten (10) days before the deadline for receipt of proposals. The interested party must confirm telephone conversations in writing.

Two types of questions generally arise. One may be answered by directing the questioner to a specific section of the RFP. Other questions may be more complex and may require a written amendment to the RFP. The procurement officer will make that decision.

SEC. 1.07 RETURN INSTRUCTIONS

Offerors must submit their proposals via email. The technical proposal and cost proposal must be saved as separate documents and emailed to doh.procurement.proposals@alaska.gov as separate, clearly labeled attachments. The email must contain the RFP number in the subject line.

The maximum size of a single email (including all text and attachments) that can be received by the State is twenty-five (25) megabytes (mb). If the email containing the proposal exceeds this size, the proposal must be sent in multiple emails that are each less than twenty-five (25) mb.

Please note that email transmission is not instantaneous. Similar to sending a hard copy proposal, the State recommends sending it enough ahead of time to ensure the email is delivered by the deadline for receipt of proposals.

It is the offeror’s responsibility to contact the above email address to confirm that the proposal has been received.

The State is not responsible for unreadable, corrupt, or missing attachments.

SEC. 1.08 ASSISTANCE TO OFFERORS WITH A DISABILITY

Offerors with a disability may receive accommodation regarding the means of communicating this RFP or participating in the procurement process. For more information, contact the procurement officer no later than ten (10) days prior to the deadline for receipt of proposals.

SEC. 1.09 AMENDMENTS TO PROPOSALS

Amendments to or withdrawals of proposals will only be allowed if acceptable requests are received prior to the deadline that is set for receipt of proposals. No amendments or withdrawals will be accepted after the deadline unless they are in response to the State's request in accordance with 2 AAC 12.290.

SEC. 1.10 AMENDMENTS TO THE RFP

If an amendment is issued before the deadline for receipt of proposals, it will be provided to all who were notified of the RFP and to those who have registered with the procurement officer after receiving the RFP from the State of Alaska Online Public Notice website.

After receipt of proposals, if there is a need for any substantial clarification or material change in the RFP, an amendment will be issued. The amendment will incorporate the clarification or change, and a new date and time established for new or amended proposals. Evaluations may be adjusted as a result of receiving new or amended proposals.

SEC. 1.11 RFP SCHEDULE

The RFP schedule set out herein represents the State’s best estimate of the schedule that will be followed. If a component of this schedule, such as the deadline for receipt of proposals, is delayed, the rest of the schedule may be shifted accordingly. All times are Alaska time.

ACTIVITY TIME DATE

Issue Date / RFP Released October 17, 2024 Deadline to Submit Questions January 7, 2025 Deadline for Receipt of Proposals / Proposal Due Date 2:00 p.m. January 17, 2025 Proposal Evaluations Complete January 31, 2025 mailto:doh.procurement.proposals@alaska.gov

Notice of Intent to Award February 14, 2024 Contract Issued February 24, 2024

This RFP does not, by itself, obligate the State. The State's obligation will commence when the contract is approved by the Commissioner of the Department of Health, or the Commissioner's designee. Upon written notice to the contractor, the State may set a different starting date for the contract. The State will not be responsible for any work done by the contractor, even work done in good faith, if it occurs prior to the contract start date set by the State.

SEC. 1.12 ALTERNATE PROPOSALS

Offerors may only submit one proposal for evaluation. In accordance with 2 AAC 12.830 alternate proposals (proposals that offer something different than what is asked for) will be rejected.

SEC. 1.13 NEWS RELEASES

News releases related to this RFP will not be made without prior approval of the project director.

SECTION 2. BACKGROUND INFORMATION

SEC. 2.01 BACKGROUND INFORMATION

Since 2019, the Alaska DOH, DPH, SOE has used NBS to house infectious disease and environmental health data that are statutorily and regulatorily mandated to be reported to the Alaska DOH. The NBS application is a Centers for Disease Control and Prevention (CDC)-developed system used by many state, tribal, local, and territorial (STLT) public health departments for infectious disease surveillance. NBS integrates information from many sources, acting as an endpoint for electronic feeds, including electronic lab reporting (ELR) and electronic case reporting (eCR) feeds. The development, monitoring, and maintenance of these inbound electronic feeds, including the monitoring and maintenance of the division’s integration engine, Rhapsody, are critical to timely identification of disease transmission. NBS also enables the sending of notifiable disease data to the CDC. Likewise, the development, monitoring, and maintenance of outbound feeds are critical to national, and other external, surveillance and intervention efforts.

It is also relevant to note that the landscape of public health surveillance has been rapidly evolving over the last four years due to the public health infrastructure gaps and weaknesses that were exposed during the management of the COVID-19 public health emergency. Surveillance systems are modernizing, which is why the Alaska DOH, DPH, SOE plans to migrate from its current NBS 6.0.x version to NBS 7.x. Independent of this migration, the SOE requires a vendor with the ability to adapt to shifting priorities, emerging diseases, and new expectations and technologies for federal reporting. It is critical to have an innovative, active partner who can implement, and even be at the table for, the federal and joint solutions being developed to improve interoperability and the data systems that support critical surveillance activities and epidemiological analyses to improve the health of people in the state of Alaska.

SECTION 3. SCOPE OF WORK & CONTRACT INFORMATION

SEC. 3.01 GOALS AND OBJECTIVES

The critical goals and objective of this contract are:

To outline the structure for a collaborative approach to NBS support, where the SOE and vendor are working closely together to understand the interface of technical and epidemiological needs. To support this collaboration—given the nature of the NBS and its development, along with the nature of coordinating ELR and eCR projects, where issues may need to be revisited again and again over time—it is critical to have an easily navigable system for the documentation of conversations, deficiencies, implemented fixes, etc. Communication and collaboration are especially important as the NBS is undergoing new development to create a modernized application. A vendor will need to understand the priorities of the modernization process and understand the needs and priorities of the SOE, to contribute to the modernization process, and possibly to work in parallel to that process to implement system capabilities more quickly for the SOE when needed. It is critical, during this modernization effort and in the normal day-to-day, that the database and inbound and outbound feeds are monitored, and that data are easily extractable by end users to support surveillance activities and epidemiological analyses, as well as recurrent grant reporting requirements.

SEC. 3.02 SCOPE OF WORK

The current Alaska version of NBS, version 6.0.16.1, is hosted in an off-site, vendor-owned cloud that is not NBS 7.x-compatible. The successful vendor must provide an NBS 7 compatible system, to include all hosting, server migration, and system migration. This is provided in further detail in Section 3.03 Deliverables. The scope of this effort requires the contractor to employ modern customer experience (CX) and human-centered design (HCD) techniques to conduct discovery/user research around the needs and goals of relevant NBS stakeholders, and the use of agile development and development, security, and operations (DevSecOps) methodologies to build the deliverables outlined in Section 3.03 and deploy them to production.

As is customary in agile development, the priorities and exact sequencing of when certain functionalities will be built are subject to change based on the natural evolution of the SOE’s and the vendor’s understanding of the problem space through continued discovery, user research, and partner engagement. The prioritization and sequencing of when and how specific functionalities listed below will be built, will be managed by the cognizant SOA NBS coordinator and achieved through a regularly updated product roadmap process. When priorities do shift, the SOE and the vendor will collaborate to establish a shared understanding of the work using standard agile practices such as product road mapping, backlog prioritization, and sprint planning.

All relevant activities are further outlined in Section 3.03 - Deliverables. Please note that in the case of a vendor-hosted option, while the Alaska DOH must approve a vendor’s security plan, there is limited involvement with Alaska DOH Information Technology (IT) in day-to-day functioning.

In the future, the SOE’s intention is to pilot NBS version 7.x in a centrally hosted CDC Azure cloud. This pilot would cover server (cloud-to-cloud) and application migrations. In this scenario, offerors will need to provide services in the centrally hosted CDC Azure cloud environment that fall into three (3) service areas—NBS interface support, NBS application support, and Alaska-specific application development—and will possibly need to provide services pertaining to the migration of the NBS to the CDC cloud.

The centrally hosted CDC Azure cloud option is currently undergoing review by the Alaska DOH. While the division does anticipate approval, outside of information presented in this RFP the exact details and scope of that project are unknown at this time. Please see Section 3.19 for more information on how this will be handled after contract award.

SEC. 3.03 DELIVERABLES

The contractor will be required to provide the following deliverables:

A. INTERFACE SUPPORT (DELIVERABLE 1)

1. NBS Data Ingestion:

a. Act as a technical point of contact on behalf of Alaska for the coordination, communication, and resolution of infrastructure-related queries, including participating in appropriate technical forums and liaison groups as directed by Alaska, for example:

i. Act as technical point of contact for the onboarding of interjurisdictional feeds;

ii. Act as technical point of contact for trading partners to onboard new feeds;

iii. Act as technical point of contact with national ELR contacts, such as the Association of Public Health Laboratories (APHL) Informatics Messaging Services (AIMS) platform, and configure the system appropriately to align with AIMS updates; and

iv. Collaborate with the SOE to maintain a list of key point of contacts at ELR and eCR reporting facilities.

2. NBS Data Porting and Outbound Feed Support and Maintenance:

a. Support legacy data porting method;

b. Act as technical point of contact for CDC Message Mapping Guides (MMGs), and/or other standard CDC pathways for case reporting to the CDC; and

c. Act as technical point of contact for NEDSS notification interface and troubleshooting.

3. Interface Monitoring and Event Management:

a. Monitor volume discrepancies and message failures and proactively respond to potential issues, such that a service level agreement (SLA) is maintained for automated inbound and outbound message feeds, for example:

i. Maintain outbound feeds to CDC endpoints for nationally notifiable conditions to an SLA of one hundred (100) percent message status reporting and ninety-nine point nine (99.9) percent messages successfully transmitted within twenty-four (24) hours;

ii. Maintain existing ELR feeds to an SLA of one hundred (100) percent message status reporting and ninety-nine point nine (99.9) percent messages successfully received;

iii. Summarize health level 7 (HL7) message failure causes and collaborate with SOE, and sending facilities, to receive corrected messages for reprocessing; and

iv. Transmit copies of all ELR, electronic initial case reporting (eICR) and reportability response (RR) messages to the SOE.

b. Collate and report metrics, summarizing inbound/outbound message flow volume, and analyze these metrics to identify common causes of error as an input to a process of continual improvement.

B. APPLICATION SUPPORT (DELIVERABLE 2)

1. NBS Help Desk and User Training:

a. Establish a support or help desk system, including on-call support, for tracking and resolving service requests, incidents, and problems to an appropriate SLA:

i. Provide self-service submission capabilities such that end-users can submit requests via a standard interface such, as a web form or email;

ii. Provide a self-service reporting capability such that Alaska NBS managers can view case details and summary metrics; and

iii. Provide a prioritization of requests with average response and resolution times (for example, high, critical, low, etc.) to set appropriate user expectations.

b. Establish, in agreement with the SOE, SLA for turnaround times.

c. Prioritize and handle incidents and respond to disruptions of normal operations, such that normal service is restored as per the SLA.

d. Respond to service requests, such as:

i. Account management requests, to include but not be limited to:

1. Resetting passwords, provisioning new accounts, detection of inactive accounts, and/or updating personal information;

ii. Incident (fix) requests, such as:

1. Troubleshooting problems encountered with labs and case reports coming into the Alaska NBS;

iii. Informational requests, to include:

1. Responding to questions from the Alaska SOE staff related to functional aspects of the Alaska NBS;

iv. Respond to legislative inquiries; and

v. Respond to audit requests from State of Alaska-designated entities.

e. Work Requests, to include:

i. Implementation of ELR and eCR in accordance with meaningful use standards; and

ii. Implementation and integration of the Alaska NBS MMG modules provided by CDC.

f. Develop agreed-upon protocol, such that there is a standardized approach to request an incident resolution, for example, a high-level estimate (HLE) of the level of effort will be provided for requested services within the requested timeline. Each estimate, at a minimum, shall include the following information: requirements, tasks, deliverables, resources, anticipated timeline, and a not-to-exceed cost that does not exceed the rate(s) set forth on the cost proposal to the contract. The Alaska SOE shall not pay any investigatory charges related to contractor’s development of an HLE. The Alaska SOE will either decline the proposed solution; propose a modified solution and request an updated HLE; or approve the proposed solution and HLE without modification.

g. Proactively eliminate recurring incidents, remove defects from the IT infrastructure, and stabilize the environment as per problem-management best practices.

2. Project Management Planning and Reporting, to include:

a. Host biweekly meetings, at a minimum, to discuss ongoing requests and projects. Relevant topics may include a summary of status, resources, schedule, tasks, activities, milestones, and risks; a summary of all opened and closed tickets for the week; a listing of tasks that were delayed and reasons for delay, with expected revised completion; planned activities for the next scheduled period, and a written summary of all major concerns or issues, and whether any such issues may impact the HLE and require a contract amendment;

b. Host a monthly project management meeting with Alaska project directors to review overall status and operations once steady state production has been achieved; and

c. On an as-needed basis, as determined by the Alaska SOE, hold analysis and design sessions for new service requests.

3. Business Analysis:

a. Provide a minimum capacity to identify emerging business needs and requirements with respect to Alaska disease surveillance and case management, analyze requirements, evaluate potential solutions, and inform future design and implementation activities, for example, via addition to and refinement of an Agile backlog.

4. Service Level Management:

a. Define, maintain, and track performance against appropriate SLAs for non-functional requirements, including but not limited to system availability, system performance, data confidentiality and integrity, and inbound/outbound message traffic; and

b. In the event of an SLA breach, take appropriate corrective actions to promote compliance with agreed-upon standards.

5. Change and Release Management:

a. Plan, schedule, communicate, and track infrastructure changes, using appropriate tools and deployment automation.

6. Service Financial Management:

a. Monitor, manage, and report resource utilization and burn rate such that Alaska can make informed and timely decisions with respect to cost optimization and financial tradeoffs; and

b. Budget and model financial scenarios as needed to ensure contract compliance against projected resource needs, and to identify potential cost savings.

7. Knowledge and Workforce Management:

a. Capture, collate, and maintain an accessible knowledge base of technical specifications, solutions to common problems, best practices, and lessons learned;

b. Prepare and maintain technical onboarding materials so that knowledge gaps due to staff changes are minimized; and

c. Obtain and maintain a set of certifications (software/cloud provider, project management, Agile, etc.) and/or other training to ensure that resources put forward for roles have minimum skills necessary for effective execution of responsibilities, for example, AWS (Amazon Web Services) Certified Cloud Practitioner or AWS Certified Solutions Architect.

8. Measurement and Reporting:

a. Provide summary statistics for case activity, database growth, inbound and outbound message volume, and other system utilization metrics as appropriate to evaluate system value delivered with respect to business need.

C. ALASKA-SPECIFIC INFRASTRUCTURE SUPPORT (DELIVERABLE 3)

1. Compile and maintain a list of all customizations and/or enhancements made to the base NBS installation, including new interfaces, custom reports, custom Rhapsody routes, Robotic Process Automation (RPA) scripts, etc.;

2. Support and maintain methods of data ingestion:

a. Catalog and operate required NBS integrations and related data flows, including automated ELR, eCR and eICR feeds, Enhanced HIV/AIDS Reporting System (eHARS) reporting, Message Validation, Processing, and Provisioning System (MVPS), AIMS platform, and others to an agreed-upon SLA, including:

i. Maintain Rhapsody, or, if applicable, other most highly recommended and/or required integration engine(s) for NBS, for processing incoming messages;

ii. Provide Rhapsody support to include a review of Alaska-specific route customization and suggestion of optimizations and/or changes; and

iii. Maintain a method of importing and converting csv flat files to HL7 electronic laboratory messages for digestion into the NBS system.

3. Maintain and support methods of NBS data extraction:

a. Provide end-user access to all data in the analytics repository (currently NBS RDB

[Reporting Database], though subject to change), for example, via a read-only copy of the RDB, at a minimum. Work with Alaska IT to ensure that access is accomplished abiding by their standards;

b. Collaborate and provide support with the creation of reports, views, and database queries;

c. Ensure all out-of-the box reporting functionality is available and functioning appropriately for the Alaska SOE’s use; and

d. Develop reports as needed for grant metrics or other monitoring, based on an agreed level of effort, with a minimum standard being a sufficient number and type of reports to ensure Alaska is compliant with local, state, and federal regulations and grant requirements.

4. Maintain a customization and enhancement backlog, and provide software development capacity sufficient to deliver prioritized stories at an agreed velocity, for example, X new custom reports, Y new features, and/or Z new configured interfaces per every N sprints, to include at minimum:

a. A process for ad hoc requests for reports, extracts, or enhancements;

b. Customize reports and extracts to be used by Alaska NBS users;

c. Customize Rhapsody routes to improve current data integration and to implement new data integrations;

d. Customize data extractions to be used by Alaska NBS users;

e. Work with trading partners to develop new feeds, and to improve the functionality of existing feeds to meet Alaska targets for ELR ingestion by program in accordance with meaningful use standards;

f. Deploy updated pages (for example, Page Builder pages)

g. Provide support for locally defined fields, questions, and value sets and configure pages, question sets, and value sets appropriately to support both nationally-notifiable and Alaska-user requirements;

h. Otherwise support Alaska NBS users who are developing new pages;

i. Ensure the value sets in NBS are up to date and in accordance with national messaging guidelines;

j. Collaborate with other states that are building pages when there is no central CDC standard in place; and

k. Support configuration of Workflow Decision Support (WDS), Alerting, and other NBS features.

5. Procure, operate, and maintain an appropriate set of test tools, data, and acceptance test cases such that new features and enhancements can be validated in an automated way.

D. MIGRATION (DELIVERABLE 4)

1. Provide virtual server migration of databases and any other integrations that might require migration services for the deployment of NBS version 7.x in a compatible cloud environment hosted by the vendor.

E. HOSTING INFRASTRUCTURE AND PLATFORM MANAGEMENT (DELIVERABLE 5)

1. Technical Objectives

a. Procure and oversee the use of cloud infrastructure on behalf of Alaska SOE for the purpose of operating NBS, including monitoring system performance, managing capacity, resolving incidents, ensuring system availability, and driving continuous improvement as described below; configuration of environments to comply with Alaska State security standards:

i. Maintain a single sign-on (SSO) system with multifactor authentication (MFA) system for users, and manage the administration of MFA system accounts;

ii. Plan, manage, schedule, and control phased rollout of IT services, updates, and releases such that the NBS application is operational across, at a minimum of two (2) environments (test and production), with optional inclusion of a third (development) environment; and

b. Implement of software patches and/or upgrades released by the NBS developer for the NBS system the implementation of a Continuous Delivery Pipeline, leveraging CDC-provided deployment artifacts such as Terraform scripts and Helm charts, to deploy and keep up to date the NBS application and necessary related software tools.

2. Service Deliverables

a. Configuration Management and Service Catalog Managements:

i. Track all configuration items required to operate NBS, including cloud resources, software licenses, personnel, and documentation; and

ii. Provide and maintain a reliable and current service catalog as a consistent repository for system information, documenting relationships between IT infrastructure systems and services.

b. Change and Release Management

i. Plan, schedule, communicate, and track infrastructure changes, using appropriate tools and deployment automation; and

ii. Deploy version updates and execute infrastructure changes in a phased approach across all environments to allow for testing and quality assurance on a scheduled cadence, to ensure Alaska production NBS is no more than two (2) minor releases behind general availability (GA), unless otherwise agreed upon with the Alaska SOE.

c. Information Security Managements:

i. Ensure that Alaska Security standards are met for initial set-up, for example, ensuring

Hypertext Transfer Protocol Secure- (HTTPS-) only access and encryption at rest, and warrant compliance with Alaska Security standards such that thereafter if changes are requested, or standards are updated, compliance and security is maintained;

ii. Provide appropriate documentation to support required security posture, for example, architecture diagrams and/or configuration information as requested;

iii. Support Alaska IT in performing required security scans and/or audits; and

iv. Monitor and log system access and report any breaches of privacy and/or confidentiality.

d. Capacity and Performance Management:

i. Provision and scale resources to meet non-functional requirements for system performance, as appropriate to load and budget; and

ii. Adjust resources in response to events to maintain appropriate capacity, pro-actively scaling resources to optimize cost.

e. Availability Management

i. Maintain system availability to the agreed SLA, for example, such that system availability is ninety-nine and a half (99.5) percent (one point eight [1.8] days of unscheduled down-time per year), Recovery Point Objective (RPO) of twenty-four

(24) hours (no more than one [1] day of lost data), Recovery Time Objective (RTO) of twenty-four (24) hours (no more than one [1] day of system down time before restoration), and Request/Incident/Problem Response times of no more than three

(3) business days/one (1) business day/two (2) hours and Request/Incident/Problem Resolution times of no more than six (6) business days/two (2) business days/twenty-four (24) hours;

ii. Schedule and communicate appropriate service windows for regular maintenance;

and

iii. Ensure that recommended system maintenance tasks are performed or are able to be performed by the Alaska SOE as outlined by the NBS development team or as stated in an up-to-date System Administration Guide.

f. Service Continuity Management:

i. Prepare, maintain, and test a disaster recovery plan, including periodically validating automated full backups of each database; and

ii. Prepare, maintain, and test a continuity of operations plan (COOP), such that NBS service can be restored to an appropriate SLA in case of data center outage and/or inability of Alaska staff to access the system normally.

g. Service Level Management:

i. Define, maintain, and track performance against appropriate SLAs for non-functional requirements, including but not limited to system availability, system performance, data confidentiality and integrity, and inbound/outbound message traffic; and

ii. In the event of an SLA breach, take appropriate corrective actions to promote compliance with agreed-upon standards.

h. Monitoring and Event Management:

i. Provide system performance monitoring to benchmark steady state and peak loads, alert on abnormal conditions, and identify any needs for improvement to interface, database, reports, and/or extract, transform, load (ETL) performance.

i. Service Validation and Testing:

i. Conduct smoke tests to confirm successful installation and user acceptance test (UAT) cycles as needed to confirm successful operation of new releases, in a phased approach beginning with lower environments;

ii. Certify new versions of software for production readiness and prepare appropriate change and configuration management assets for production release, including rollback plans to restore service in the event of issues with new releases; and

iii. Support testing of interfaces and related components in response to updates by Alaska, CDC, and/or trading partners.

j. Risk Management:

i. Maintain a risk register that identifies, evaluates, and proposes mitigations for foreseeable risks, by impact (severity & frequency) - Establish a proactive approach to anticipate and respond to potential challenges and opportunities, for example, by incorporating risk mitigation stories into a prioritized backlog.

SEC. 3.04 HIPAA SECURITY ASSESSMENT REQUIREMENTS

Once the contract is executed and prior to beginning any other work under the contract, the contractor shall work with the DOH Security Office to complete a full DOH/Health Insurance Portability and Accountability Act (HIPAA) Security Assessment for the proposed software or system solution(s). This process and the information required of the contractor is detailed in a NIST CSF Assessment Questions List (see next RFP section).

Follow up clarification questions from the DOH’s Security Assessor may be required. The software or system solution(s) must receive an Authority to Operate (ATO) from the Security Assessor prior to being implemented and deployed. If the ATO is not issued, the State is not responsible for any additional costs and reserves the right to terminate the contract immediately.

SEC. 3.05 INTENT TO PROPOSE AND NON-DISCLOSURE AGREEEMENT

To obtain the NIST CSF Assessment Questions List, the offeror must complete and submit an Intent to Propose and Non-disclosure Agreement, provided as an attachment to this RFP. The signed agreement must be emailed to the procurement officer as an attachment and the offeror must also provide the phone number and email address of the person who is to receive the file. The file will then be provided by the procurement officer to an offeror via a secure file transfer site or other method.

The procurement officer will not provide this file until receipt of the completed and signed intent to propose and non-disclosure agreement. The State reserves the right to clarify and verify any offeror’s ability to perform the services required under this solicitation prior to granting access to the file, and any proposal submitted from an offeror that does not have a signed NDA will be considered non-responsive.”

To obtain the NIST CSF Assessment Questions List, the offeror must complete and submit an Intent to Propose and Non-disclosure Agreement, provided as an attachment to this RFP. The signed agreement must be emailed to the procurement officer as an attachment and the offeror must also provide the phone number and email address of the person who is to receive the file. The file will then be provided by the procurement officer to an offeror via a secure file transfer site or other method.

The procurement officer will not provide this file until receipt of the completed and signed intent to propose and non-disclosure agreement. The State reserves the right to clarify and verify any offeror’s ability to perform the services required under this solicitation prior to granting access to the file, and any proposal submitted from an offeror that does not have a signed NDA will be considered non-responsive.

SEC. 3.06 HIPAA AND HITECH INFORMATION SECURITY AGREEMENT (ISA)

To further ensure the State meets its legal obligations regarding Protected Health Information, the contractor shall, at all times, meet all requirements set forth in the HIPAA and Health Information Technology for Economic and Clinical Health Act (HITECH) Information Security Agreement (ISA), attached with this RFP as Attachment 8, Appendix F, HIPAA and HITECH Information Security Agreement. This ISA will be included in the fully executed contract.

For DOH IT Security purposes, in the event of any conflict between these requirements and the Business Associate Agreement (BAA), the ISA supersedes the BAA.

SEC. 3.07 INFORMATION TECHNOLOGY (IT) RELATED CONTRACTUAL REQUIREMENTS

Other specific DOH IT-related contractual requirements are provided in Attachment 2 - Submittal Form H – DOH IT Contractual Requirements - SaaS Solutions. The offeror must complete this form in accordance with the provided instructions; space is provided to both choose a response (see the drop-down list) and provide further explanation.

Note that certain initial elements of the HIPAA Security Assessment indicated in Section 3.04 may be completed during the negotiation phase based on the offeror’s response to these contractual requirements.

SEC. 3.08 CONTRACT TERM AND WORK SCHEDULE

The length of the contract will be from the date of award for approximately one year, with seven additional one-year renewal options to be exercised solely at the discretion of the State.

Any extension of the contract beyond the exercised renewal options will be upon mutual agreement between the State and the contractor and effected with a contract amendment processed by the procurement officer and signed by both parties. All other terms and conditions of the contract, including those previously amended, shall remain in full force and effect. Unless otherwise agreed to by both parties, the procurement officer will provide written notice to the contractor of the intent to cancel an extension at least thirty (30) days before the desired date of cancellation.

SEC. 3.09 CONTRACT TYPE

This contract is a firm fixed price contract in accordance with Submittal Form I – Cost Proposal.

SEC. 3.10 PAYMENT PROCEDURES

The State will make payments based on a monthly payment schedule. Each billing must consist of an itemized invoice and progress report. No payment will be made until the progress report and invoice has been approved by the project director.

SEC. 3.11 CONTRACT PAYMENT

No payment will be made until the contract is approved by the Commissioner of the Department of Health or the Commissioner's designee. Under no conditions will the State be liable for the payment of any interest charges associated with the cost of the contract. The State is not responsible for and will not pay local, state, or federal taxes. All costs associated with the contract must be stated in U.S. currency.

SEC. 3.12 LOCATION OF WORK

The State will not provide workspace for the contractor. The contractor must provide its own workspace.

Travel to other locations will not be required.

By signature on their proposal, the offeror certifies that all services provided under this contract by the contractor and all subcontractors shall be performed in the United States.

If the offeror cannot certify that all work will be performed in the United States, the offeror must submit a request, set out in a separate document in their proposal, that provides a detailed description of the portion of work that will be performed outside the United States, where, by whom, and the reason that is necessary.

The offeror must also provide this information when completing the Attachment 2 - Submittal Form H - DOH IT Contractual Requirements - SaaS Solutions.

Failure to comply with these requirements may cause the State to reject the proposal as non-responsive or cancel the contract.

SEC. 3.13 SUBCONTRACTORS

Subcontractors may be used to perform work under this contract. If an offeror intends to use subcontractors, the offeror must complete the Submittal Form identified in Section 4.02 of this RFP.

An offeror's failure to provide this information with their proposal may cause the State to consider their proposal non-responsive and reject it.

Subcontractor experience shall be considered in determining whether the offeror meets the requirements set forth in Submittal Form F – Mandatory Requirements. Offerors must be specific as to which subcontractor(s) defined in Submittal Form G – Subcontractors they are citing to meet the specific requirement listed in Submittal Form F.

If a proposal with subcontractors is selected, the State may require a signed written statement from each subcontractor that clearly verifies the subcontractor is committed to provide the good or services required by the contract.

The substitution of one subcontractor for another may be made only at the discretion and prior written approval of the project director or procurement officer.

Note that if the subcontractor will not be performing work within Alaska, they will not be required to hold an Alaska business license.

SEC. 3.14 JOINT VENTURES

Joint ventures will not be allowed.

SEC. 3.15 RIGHT TO INSPECT PLACE OF BUSINESS

At reasonable times, the State may inspect those areas of the contractor's place of business that are related to the performance of a contract. If the State makes such an inspection, the contractor must provide reasonable assistance.

SEC. 3.16 F.O.B. POINT

All goods purchased through this contract will be F.O.B. final destination. Unless specifically stated otherwise, all prices offered must include the delivery costs to any location within the State of Alaska.

SEC. 3.17 CONTRACT PERSONNEL

Any change of the project team members or subcontractors named in the proposal must be approved, in advance and in writing, by the project director or procurement officer. Changes that are not approved by the State may be grounds for the State to terminate the contract.

SEC. 3.18 INSPECTION & MODIFICATION - REIMBURSEMENT FOR UNACCEPTABLE

DELIVERABLES

The contractor is responsible for the completion of all work set out in the contract. All work is subject to inspection, evaluation, and approval by the project director. The State may employ all reasonable means to ensure that the work is progressing and being performed in compliance with the contract. The project director or procurement officer may instruct the contractor to make corrections or modifications if needed to accomplish the contract’s intent. The contractor will not unreasonably withhold such changes.

Substantial failure of the contractor to perform the contract may cause the State to terminate the contract. In this event, the State may require the contractor to reimburse monies paid (based on the identified portion of unacceptable work received) and may seek associated damages.

SEC. 3.19 CONTRACT CHANGES – ANTICIPATED AMENDMENTS

In accordance with SOE’s intent to pilot NBS version 7.x in a centrally hosted CDC Azure cloud, if approval is received the SOE expects the vendor to work with the SOE in good faith to help determine the exact requirements, scope, deliverables, and reduced cost that would result from this effort. Once these details are determined, a written amendment to the contract will be processed by the procurement officer and signed by the State and the vendor. If the SOE does not receive approval for the CDC Azure cloud, the contract will continue as originally executed (including any subsequent amendments to renew or otherwise modify the contract). The State may also choose to conduct another procurement and/or terminate the contract.

SEC. 3.20 CONTRACT CHANGES - UNANTICIPATED AMENDMENTS

During the course of this contract, the contractor may be required to perform additional work. That work will be within the general scope of the initial contract. When additional work is required, the project director will provide the contractor a written description of the additional work and request the contractor to submit a firm time schedule for accomplishing the additional work and a firm price for the additional work. Cost and pricing data must be provided to justify the cost of such amendments per AS 36.30.400.

The contractor will not commence additional work until the procurement officer has secured any required State approvals necessary for the amendment and issued a written contract amendment, approved by the Commissioner of the Department of Health or the Commissioner's designee.

SEC. 3.21 NONDISCLOSURE AND CONFIDENTIALITY

Contractor agrees that all confidential information shall be used only for purposes of providing the deliverables and performing the services specified herein and shall not disseminate or allow dissemination of confidential information except as provided for in this section. The contractor shall hold as confidential and will use reasonable care (including both facility physical security and electronic security) to prevent unauthorized access by, storage, disclosure, publication, dissemination to, and/or use by third parties of, the confidential information. “Reasonable care” means compliance by the contractor with all applicable federal and state law, including the Social Security Act and HIPAA. The contractor must promptly notify the State in writing if it becomes aware of any storage, disclosure, loss, unauthorized access to, or use of, the confidential information.

Confidential information, as used herein, means any data, files, software, information or materials (whether prepared by the State or its agents or advisors) in oral, electronic, tangible, or intangible form and however stored, compiled, or memorialized that is classified confidential as defined by State of Alaska classification and categorization guidelines provided by the State to the contractor or a contractor agent or otherwise made available to the contractor or a contractor agent in connection with this contract, or acquired, obtained, or learned by the contractor or a contractor agent in the performance of this contract. Examples of confidential information include, but are not limited to: technology infrastructure, architecture, financial data, trade secrets, equipment specifications, user lists, passwords, research data, and technology data (infrastructure, architecture, operating systems, security tools, IP addresses, etc.).

If confidential information is requested to be disclosed by the contractor pursuant to a request received by a third party and such disclosure of the confidential information is required under applicable state or federal law, regulation, governmental, or regulatory authority, the contractor may disclose the confidential information after providing the State with written notice of the requested disclosure (to the extent such notice to the State is permitted by applicable law) and giving the State opportunity to review the request. If the contractor receives no objection from the State, it may release the confidential information within thirty (30) days. Notice of the requested disclosure of confidential information by the contractor must be provided to the State within a reasonable time after the contractor’s receipt of notice of the requested disclosure and, upon request of the State, shall seek to obtain legal protection from the release of the confidential information.

The following information shall not be considered confidential information: information previously known to be public information when received from the other party; information freely available to the general public;

information which now is or hereafter becomes publicly known by other than a breach of confidentiality hereof;

or information which is disclosed by a party pursuant to subpoena or other legal process and which as a result becomes lawfully obtainable by the general public.

SEC. 3.22 INDEMNIFICATION

The contractor shall indemnify, hold harmless, and defend the contracting agency from and against any third-party claim of, or liability for, error, omission, or negligent act of the contractor under this agreement.