EDSS RFP Addendum 01.pdf

STATE OF HAWAII

DEPARTMENT OF HEALTH

DISEASE OUTBREAK CONTROL DIVISION

HEALTH DATA INFORMATICS OFFICE

FEBRUARY 24, 2025

ADDENDUM 01

TO

REQUEST FOR PROPOSALS

RFP No. HTH131-2025-01

HAWAII ELECTRONIC DISEASE SURVEILLANCE SYSTEM

Pursuant to HAR §3-122-16.06, the State of Hawaii Department of Health Disease Outbreak Control Division Health Data Informatics Office hereby issues this clarification addendum to address the below items.

Request for Proposals, Electronic Disease Surveillance System Modernization, RFP No.

HTH131-2025-01, Page 2 is hereby revised to read as follows:

“The State of Hawaii Department of Health (“DOH”) is requesting proposals from qualified vendors to implement a new Electronic Disease Surveillance System (“EDSS”.) Currently, Hawaii has a legacy EDSS that does not meet the needs of the State.”

Section 2 - Service Specifications: General Requirements, subsection 2.1 Introduction, A.

Overview, history purpose or need is hereby revised to read as follows:

“The State of Hawaii, Department of Health (“DOH”), Disease Outbreak Control Division (“DOCD”) is requesting proposals for the implementation, operational support services and Software as a Service (SaaS) hosting of an integrated electronic disease surveillance and outbreak management system that is interoperable with other health information systems, including Health Information Exchanges, Immunization Information Systems, and Vital Records Information Systems, as well as federal reporting systems and standards including the National Notifiable Disease Surveillance System and the National Violent Death Reporting System. This system would replace the current electronic disease surveillance system.”

Section 5 – Service Specifications: M&O and Enhancement Requirements, subsection 5.1 M&O, C. Objective, first sentence of paragraph 2 is hereby revised to read as follows:

“A two (2)-month (60 - calendar day) hypercare period will follow implementation of the EDSS full solution go-live, for stabilization and initial enhancements.”

Section 7 – Proposal Submission Instructions, subsection 7.8 Service Delivery is hereby revised to read as follows:

A. “Offeror shall include a detailed discussion of the Offeror’s approach to applicable service activities and management requirements from Section 6.1, Scope of Work, including (if indicated) a work plan of all service activities and tasks to be completed, related work assignments/responsibilities and timelines/schedules.”

State’s responses to questions submitted by prospective Offerors via HIePRO, which were due by Wednesday, February 19, 2025, by 2:00pm HST, and questions asked in the pre-proposal conference held via Microsoft Teams on Tuesday, February 18, 2025, at 9:00am HST:

Timelines

21. We request an extension to allow adequate time to address all requirements.

Answer: The State has provided more time than is required by statute and rules and due to associated timelines, the State will not be extending the deadline for submission of proposals.

4. EDSS RFP Final - Section 2.1(F) Probable Funding - Does the mentioned 12-month implementation timeframe include the timing needed for re-onboarding of electronic message feeds and the work needed from the State, the vendor, the CDC, and APHL?

Answer: The 12-month implementation timeframe outlined in Section 2.1(F) is the DOH’s preferred ideal timeline for the initial implementation phase, inclusive of system deployment, data migration, and transition to operations. However, the re-onboarding of electronic message feeds (ELR, eCR) and coordination with the CDC, APHL, and other external partners is recognized as a complex, multi-stakeholder process with dependencies that may extend beyond the core implementation period. Offerors should account for these dependencies in their proposed project schedules and identify any potential risks or constraints associated with transitioning from the legacy system to the new EDSS. The Offeror is expected to propose a phased approach that mitigates disruptions and ensures continuity of data exchange.

7. EDSS RFP Final - 2.2 General Requirements, Section B - Our offering is a vendor-hosted COTS SaaS solution. This section refers to client access to most source code and back-end related tools used to develop our platform and application. These items are not directly available to clients. Does this section apply to SaaS offerings or only to State-hosted custom development offerings, perhaps? It is uncommon for clients to have access to and require specific toolsets to be used by established SaaS offerings with toolsets and infrastructure in place.

Answer: The requirements outlined in Section 2.2(B) primarily apply to State-hosted and custom-developed solutions. For hosted COTS SaaS offerings, the expectation is not direct access to the source code but rather adherence to industry best practices for configuration, integration, and interoperability. The Offeror must ensure the proposed solution provides sufficient administrative access, API capabilities, and configuration flexibility to support the State’s operational and security needs. Additionally, the Offeror should describe how the solution accommodates enhancements, troubleshooting, and issue resolution in the absence of direct access to underlying development toolsets. The State is open to clarifications or alternative approaches that align with SaaS industry standards while ensuring the necessary levels of transparency, maintainability, and operational control within a DOH-owned tenant.

9. EDSS RFP Final - Several sections (general question) - In many sections, the RFP lists requirements for the vendor to document and describe how they intend to develop the EDSS solution for the State. An example is an explanation of how developers will build and establish look-up tables. Many of these sections and requirements seem to apply only to a newly and custom built EDSS solution, not an existing SaaS based solution following a single-code base methodology. Can the State confirm that these general sections and requirements don’t necessarily apply to SaaS model? Or provide more clarity on the intent of these types of requests? Further, Section 6.1(A) mentions that ‘there should be no or very minimal custom software development to make the system compliant with these functional standards. Which seems to go away from some of the other language in the RFP. I think the ask is for general clarity on SaaS and a single-code base, which is the standard for SaaS solutions, vs custom developed solutions and the expectation.

Answer: The State acknowledges that certain requirements outlined in the RFP may not be directly applicable to SaaS solutions and some low-code platforms. The DOH clarifies the preference for SaaS solutions and low code in the ideal solution.

10. EDSS RFP Final - 4.5 Task 5 UAT D(6) - Section mentioned providing source code and related documentation as part of the UAT process. This would be highly unlikely for a SaaS solution. We’d be unable to share the source code directly with the State. Is this a requirement only meant for custom developed solutions and not applicable to vendor-hosted SaaS offerings?

Answer: The requirement to provide source code and related documentation applies primarily to custom-developed solutions. For hosted SaaS offerings, vendors are not required to provide direct access to source code other than custom components. However, vendors must ensure compliance with testing, security, and documentation requirements to facilitate UAT and system maintainability. This includes providing appropriate system documentation, data access, API specifications, and necessary environments to support validation and support efforts. Please refer to the RFP section copied below.

RFP Section 2 Service Specifications: General Requirements “Source Code Management (“SCM”) tool to store and manage multiple versions of computer programs and files. Together, the ALM and SCM must contain the source code and technical documentation. The DOH prefers to use MS Azure DevOps for SCM. The DOH expects the Offeror to document the approach, processes, and roles and responsibilities related to use of the SCM tool in the Software Development Guide. An SCM in a format acceptable to the DOH must be provided for source code.”

11. EDSS RFP Final - 6.1 Introduction A. System Requirements (4) - This section specifically mentions that the solution will be hosted in a DOH owned tenant but then also that the vendor will provide the cloud hosting services. Does this mean the State is looking for the solution to be hosted on a State-owned cloud, or is open to a vendor cloud but the State requires a unique tenant? Also, can the State define ‘under State licenses’ as it refers to the tenant? Later in the same section, it requires DOH IT Staff to have full and direct access to all production and non-production environments. Does this specifically mean direct database and backend access to the DOH team? Or does this mean front-end access? The section mentions we must provide our SOC2 on a yearly basis. Providing clients with direct database access and full admin authority over systems would inherently break our SOC2 compliance. Generally, hoping to get clarity on what DOH requires in this section.

Answer: The DOH has a stated strong preference for the EDSS solution to be hosted within the State’s cloud hosting services under the DOH’s administrative controls. The DOH is ideally looking for the solution to be hosted on a State-owned cloud. The State may consider proposals for an Offeror cloud with a DOH tenant for the State’s EDSS. The DOH would require the ability to directly query the reporting database and have system admin access for oversight functions not limited to user audit logs. The SOC2 compliance requirement would then only apply to an Offeror-hosted cloud.

12. EDSS RFP Final - 6.1 Introduction A. System Requirements (5) - Does this section mean the intent of the State is to host the new EDSS in the State’s Azure cloud?

Answer: Yes, the intent of the State is to ideally host the new EDSS in the State’s Microsoft Azure cloud environment. Per Section 6.1(A)(5) of the RFP, the Offeror shall propose an EDSS core system that maintains disease case surveillance functionality and supports data management within the DOH’s data environments and enterprise data warehouse, which is located in the DOH’s Microsoft Azure environment. Additionally, Offerors are required to leverage and configure the DOH’s Azure instances relative to the EDSS, including tools for data cataloging, data quality, and business intelligence reporting tools.

45. RFP Attachment E RTM, Enterprise Arch Regs, E9 - RFP Language: Offeror must describe the solution's ability to support the DOH's preferred full complement of multiple hosted environments/instances (e.g., DEV/SIT/UAT/TRAIN/PROD), and any justification for a different mix of production and non-production instances. Offeror must confirm DOH staff shall have access to all these environments, in a DOH-owned tenant. Question: Would DOH consider hosting the solution in a vendor-owned tenant, with DOH staff being granted access to the hosted environments?

Answer: Refer to Question 11 & 12

57. Section 2.2.A - The Offeror’s system must be a fully implemented COTS system in at least two (2) public health jurisdictions and providing the ability to support all CDC-defined case definitions Q: Would the State be open to expanding this requirement to include other technology solutions beyond COTS (i.e., low code platforms)?

Answer: The DOH may consider proposed technology solutions that leverage low code platforms in addition to COTS solutions, given the previously stated requirement for a very low percentage of custom code.

20. Can you confirm the implementation budget for Year 1 is $2 million?

Answer: This is an estimation for Year 1 and shall not be used as a final budget for this project.

The DOH may consider adjustments to this budgetary projection, depending on the range of Offeror responses and system capabilities.

37. The RFP outlines funding constraints but does not specify flexibility. Will additional funding be available for unanticipated enhancements during the contract term?

Answer: The State recognizes and acknowledges that there may be unanticipated enhancements to the system and can account for some flexibility. This may include but not be limited to considerations around integrations and additional components such as the MPI.

MPI

1. Section 4.1, D, 11c; Develop a Technical Solution Document: Is the MPI portion going to be only used for records for EDSS or will other records from other systems (i.e.

Medicaid) be added and expected to link match to records EDSS.

Answer: The DOH expects the MPI component to be leveraged initially for the EDSS and link and match records to the Immunization Information System and DOH enterprise data warehouse. The MPI solution is anticipated in the future beyond the initial EDSS project scope to match and deduplicate records with other systems such as but not limited to those from Vital Records, Medicaid, the State LIMS, and other systems.

13. EDSS RFP Final - 6.1 Introduction A. System Requirements (7) - Is the cost of the MPI or MDM tool and offering to be included in the overall cost of the project? And was this cost assumed as part of the initial $2M for the first 12-month cycle?

Answer: The DOH anticipates the licensing and integrating of this tool within the EDSS to be included in the overall project. This MDM tool-related licensing and integration costs may be considered in addition to the initial budgetary estimate.

15. EDSS RFP Final - 6.1 Introduction A. System Requirements (7) - Does the State have an MPI that they are currently using?

Answer: No. The DOH does not currently leverage an MPI or MDM solution.

23. RFP Section 6.1 A.7: Within the MDM section in the proposal there is mention of an “Offeror-subcontracted partner”. If possible, can there be more details on the definition of this and the nature of the intended relationship. There are also only 4 requirements in the RTM sheet with reference to the MDM component. If there are more technical requirements around interfaces, scale or governance that would be helpful for estimation purposes.

Answer: The DOH anticipates the Offeror to provide configuration of this tool either via specific Offeror staff or through an Offeror-subcontracted partner, with demonstrated experience in this tool. The Offeror is expected to propose associated activities to support the MDM component configuration and use in the EDSS aligned with industry best practices.

Question 60: (Request clarification - "The offeror shall additionally propose and describe a master patient index or master data management component to be leveraged for single central identity management. This MPI shall be used for all patient identity resolution and master provider directory within the EDSS and shall leverage a COTS product for this EDSS component. The DOH strongly prefers that this component be offered through an Offeror-subcontracted partner"), Answer: The offeror must propose an MPI and MPD component for central identity management within the EDSS. The DOH clarifies the component must: Be a commercial off the shelf (COTS) product, serve as a single identity resolution and master provider directory, be provided by an offeror subcontracted partner or Offeror team with this expertise, with DOH maintaining all MPI or MDM tool-related licenses.

Contracting and Procurement

2. EDSS RFP FINAL - Administration Overview 1.1 Procurement Timetable. Seeking clarification on the demo process and where that will fit within the decision timeframe?

How many vendors will be chosen for demos and when will those demos be?

Answer: If demos are to be requested by the State, they will be requested from and provided by offerors who are selected for the BAFO phase of the solicitation.

17. Attachment A, page 2 - Are we allowed to submit a proposal if we do not have a Hawaii General Excise Tax ID No., but agree to get one prior to contract award?

Answer: A Hawaii General Excise Tax number is required to enter into a Contract with the State of Hawaii. If a HCE certificate is not being submitted with the Offeror’s proposal, a HIDOTAX clearance certificate is required to be submitted with the Offeror’s proposal. It is highly recommended that the Offeror apply for a GET as soon as possible as this is also used to prove compliance in HCE.

18. Attachment D Proposal Offer Form OF2 - Can the State please provide this form in a Microsoft excel format?

Answer: Offerors are asked to edit the PDF to input the information.

19. Attachment F Reference Form - Can the State please provide some additional space to provide a summary of context for why this organization is a reference?

Answer: The Offeror may attach a page to the Reference Form to provide a description and summary of context.

41. Where in the proposal should we log exceptions?

Answer: Exceptions shall be submitted as a separate document to the proposal. Note: Any proposals offering any other set of terms and conditions contradictory to those included in this RFP may be rejected without further notice.

42. RFP Attachment B - Question: Are we to include the General Conditions and Special Conditions sections in our response?

Answer: No, as per Attachment B, Proposal Submission Checklist instructions, the Offeror is only required to acknowledge that the Offeror has read, understands, and agrees to the General and Special Conditions attached to the solicitation.

43. RFP Attachment B - RFP Language: Offerors shall place an X in the column to confirm that the Offeror has read and agrees to all General and Special Conditions attached to the RFP. Question: If we raise exceptions to items in General and Special Conditions, do we still check X in the columns?

Answer: If an Offeror does not agree to the General and Special Conditions attached to the solicitation, it shall NOT place an X in the box stating the Offeror has read and agrees to all General and Special Conditions attached to the solicitation. Refer to Question #41 for exceptions.

Evaluation

44. RFP Attachment K - Question: The Evaluation criteria indicate we will be scored on Project Approach and Proposed Approach. These sections are not listed in Attachment B Proposal Checklist. Where should we place these items in our response?

Answer: The "project approach" and "proposed approach" sections should be placed under Service Delivery in the proposal response. The Proposal Document Requirements listed in the RFP (Section 7) do not explicitly reference a separate section for these topics. Service Delivery is the appropriate category where methodology, system approach, and implementation strategies should be addressed.

47. RFP Attachment E, RTM, General Regs, G9 - RFP Language: The STATE seeks professional services provided by the contractor to meet the deliverables as defined in the Deliverables and Estimated Schedule in order to achieve the objectives of this project.

Describe your strategy for accomplishing the professional services Question: Please indicate where the Deliverables and Estimated Schedule is located.

Answer: There is no “Deliverables and Estimated Schedule” document. The Offer Form (OF2) includes all deliverables and an estimated schedule. The deliverables are detailed throughout the entire RFP and there is also a timeline table included in section 3.1.

55. RFP Section 1.20 General and Special Conditions of Contract, Section 1, pg 16 - RFP Language: If an award is accepted, the successful Offeror will be required to enter into a formal written contract with the State. The Contract shall include or be deemed to incorporate this RFP, the Contractor's Proposal or BAFO, State AG General Conditions set forth in Attachment G, Special Conditions set forth in Attachment H, and any other terms as may be agreed to by the State and the Contractor. To the extent that the RFP and the successful proposal conflict, the terms of the RFP shall govern. By submitting a proposal, the Offeror certifies that they have read and agree to all General Conditions and Special Conditions attached hereto. Question: Please confirm that neither the State nor the successful Offeror will be bound until they have had the opportunity to negotiate and mutually agree on the final fully signed contract.

Answer: Offerors may submit exceptions, however, refer to Question #41 for exceptions. No parties are bound until a Contract is fully executed by all parties.

Question 67: If our vendor organization is unable to sign an external parties’ contract and must instead have the DOH sign our contract, would it be prudent to note any exceptions right off the bat that we may have within our proposal? Or is this just a non-starter?

Answer: The State requires Contractors to enter into and bind themselves to a Contract drafted by the State of Hawaii. The Contract form as well as General and Special Conditions are included as attachments to the solicitation. Exceptions are addressed in Question #41.

Training and Service: General Requirements

6. EDSS RFP FINAL - 2.2 General Requirements, Section B - For clarity, does the State expect the vendor to train DOH staff on the use and maintenance of SharePoint?

Answer: The DOH expects the Offeror to train DOH staff on the use and maintenance of the EDSS system and all associated components. This may include but not be limited to training on navigating and updating system documentation in the SharePoint.

30. Will you have staff dedicated to the implementation to assist as SMEs for requirements and knowledge transfer? Will you have staff available during the implementation that have a thorough understanding of your legacy database configuration?

Answer: Yes. The DOH has an identified list of multiple technical SMEs and a longer list of program-area SMEs with time dedicated to assist with knowledge transfer.

35. The RFP states that training should be conducted. Will the State require training for external stakeholders such as healthcare providers and labs, or just internal users?

Answer: The DOH anticipates training material and at minimum recorded training is required for the use of external stakeholders. This is anticipated to be a reduced quantity of training activities versus internal stakeholders.

36. The RFP states that incremental demonstrations will be required. Will the State provide dedicated testers for UAT, or is the vendor expected to staff testing resources?

Answer: The DOH expects to provide program and technical staff to support UAT, with an expectation of vendor staff providing planning and support. These resources for UAT would be based on a UAT Plan inclusive of vendor-provided and State-agreed test cases.

38. The RFP references a bank of enhancement hours per year. Will unused hours carry over to the next year, and can they be reallocated to other services?

Answer: Yes, the DOH expects the enhancement hours to be reallocated within the project support services. The DOH expects these would carry over month-to-month but not carry over year-to-year. The Offeror should anticipate providing a monthly accounting of these services hours promptly at the conclusion of each month, in order to plan enhancements.

Service Expectations

40. RFP Attachment E, RTM, Prod Support Tab, P25 - RFP Language: Describe if you meet the response times listed in the Technology Contract – Attachment C, Exhibit C.

Question: Attachment C appears to be the Sample Table of Contents. Will the state provide the document with listed response times?

Answer: Offerors should propose their service level commitments in alignment with industry best practices for system availability, issues resolution, and user support. The DOH’s expectations are these should be based on the information provided in the RFP on page 89-90 table on Ticket Priority Levels and Descriptions, and the page 103-104 section and table for Problem Response.

Question 58: A. (Request clarification on requirements for references - "previous successful implementation from separate public health jurisdictions" and "two of these references must be where the Offeror's fully function EDSS has been implemented...") B. Is that a minimum requirement or a scored requirement?

Answer: The reference requirement is part of the evaluation criteria and is considered during the proposal assessment. Proposals that meet or exceed this requirement will receive a higher evaluation score.

5. EDSS RFP Final - Service Specifications 2.1 Introduction Section C - Will healthcare providers be logging into the EDSS directly?

Answer: Yes, the DOH anticipates an estimated 100 healthcare provider users to require direct access to the EDSS.

24. Could the DOH comment on the anticipated internal users as well as external Provider (portal) users?

Answer: The DOH anticipates approximately 200-300 internal users.

Onboarding

Question 63: 1. (Request clarification regarding the vendor's role in onboarding healthcare vendors on establishing HL7 connections with other healthcare providers and associated systems) Answer: The Offeror is not required to facilitate onboarding of existing or future providers and/or clinicians via HL7 format, as the back-end interfacing is supported for DOH via the existing Rhapsody Integration Engine. The Offeror is responsible for confirming ingestion of HL7 messages in native format into the environment.

Question 65: What is the vendor’s role in onboarding electronic messaging (ELR, eCR, facilities, labs) during Phase 1 and Phase 2?

Answer: During phase 1 the vendor is expected to implement core disease surveillance functions including re-establishing a HL7 2.5.1 intake of incoming messages in native format and Electronic Initial Case Reports ingested natively in their original XML format for EDSS population. New facilities and labs will be onboarded by the DOH team through existing pathways and routed to the EDSS via the DOH’s Rhapsody Integration Engine. In phase 2 the vendor will assist in expanding base modules to support additional disease and/or condition groupings and support the onboarding of additional DOH divisions and programs. The Offeror will create, with input from the Hawaii DOH staff, a protocol for condition onboarding and maintenance. Refer to the section 4.7 User Training for requirements around the content and structure for this training curriculum.

Question 66: How should the project schedule account for the complexities of onboarding electronic messaging? (ELR, ECR) (role of the vendor leading and assisting) How should dependencies in electronic messaging be handled when transitioning from one system to another? Are there any specific requirements or expectations in the RFP for handling these dependencies? (e.g., clarification of vendor services versus States responsibility for that onboarding) Answer: The Offeror is responsible for the testing of incoming HL7 messages and electronic initial case reports (eICR) ingestion in their native formats (hl7 and xml) into the environment.

This will include confirmation of appropriate proliferation of identified data elements for review, aggregation and placement of ingested data into various front-end data viewing mechanisms. The Offeror will additionally be responsible for maintaining any delta changes between the legacy system’s databases up to, and exceeding go-live of the new EDSS project.

14. EDSS RFP Final - 6.1 Introduction D Implementation Req (4) - Does the State require direct help from the vendor to re-onboard all ELR/eCR feeds currently in production including partnership with CDC/APHL to create and test onboarding mechanisms?

Answer: The Offeror will be required to support the testing and validation of ingestion mechanisms into the EDSS for ELR/eCR feeds via the existing integration engine, Rhapsody.

For newer formats that are not already explicitly ingested and where no mechanism currently exists, such as FHIR, the Offeror will be required to support DOH in onboarding and buildout of interfaces as needed to support ingestion.

16. EDSS RFP Final - 6.1 Introduction E System Maintenance (3j) - The State references NSSP BioSense in the standards and requirements; is the State expecting syndromic data to be part of the EDSS solution? Also, would the STATE be interested in a dedicated installation of ESSENCE to support their syndromic needs?

Answer: The State is interested in proposals defining the use-case of a dedicated installation of ESSENCE, in compliance with federal data use agreements that maintain similar query availabilities as provided by the online instance of the BioSense ESSENCE platform.

49. RFP Attachment E RTM, Business Regs, R71 - RFP Language: Support enhanced collaboration between NHSN, ARLN, and EDSS to reduce silos and improve data flow across platforms. Question: Will the state elaborate on the context of collaboration? For examples, is this an integration requirement?

Answer: The Offeror will assist in defining architecture to ensure, at minimum, the capacity to automate the ingestion of NHSN and ARLN data in conjunction with the integration interface engine, Rhapsody.

3. EDSS RFP FINAL - Service Specifications 2.1 Introduction Section C - Can the State provide the 18 program areas that will be utilizing the new EDSS?

Answer: The list of these program areas is provided on page 23 of the RFP as “Stakeholder Programs and Areas Engaged in the EDSS Planning Effort.”

8. EDSS RFP Final - 3.9 Coordination with Project Vendors - Coordination and work with other unknown vendors could add timing, effort, and scope to the project. Also, certain materials produced could include proprietary information normally only meant for the State. Would consideration be given for these circumstances? Including potential cost implications?

Answer: The DOH anticipates favorably considering Offeror requests to redact proprietary information. There is a DOH expectation that coordination with vendors may require schedule and cost adjustments. The coordination of project activities with DOH requires project management and/or independent verification and validation contractors. This requirement aligns with industry best practices.

22. RFP Section 2.2 A: In this section there is reference to the qualifications of the solution with the use of “must” as a qualifier in the conditions. Will these qualifications be scored or are the mandatory (pass/fail)?

Answer: Please refer to the last sentence in subsection A. Offerors who do not meet those qualifications will be awarded less points than those who do.

26. Regarding Req No. R16 in the matrix, "Capability to customize investigation forms with conditional required fields and summary views for missing critical questions", can we receive clarification on "Summary views for missing critical questions"? Is this just requesting a way to summarize any data entry that was missed?

Answer: The requirement refers to the system's capability to provide a summarized view highlighting missing critical data fields in investigation forms. This ensures data completeness by flagging required fields that have not been completed.

27. Regarding Req No. R25 in the matrix, "System must track dropped or newly added cases and highlight changes for review", can we receive clarification on what is needed to "highlight changes for review"?

Answer: The system must track newly added or dropped cases and highlight modifications for review. This includes displaying changes in case status, demographics, or key data fields in a way that allows reviewers to quickly identify updates for validation.

28. Regarding Req No. R73 in the matrix, "Allow customizable reports at the user-role-level and user level, and support data extraction without the use of reports", can we receive clarification on what is expected for "Data extraction without the use of reports"?

Answer: The requirement for "data extraction without the use of reports" refers to the system’s ability to allow users to access and extract raw data via querying of a reporting database within the environment.

29. Do you have an electronic output of the list of questions in your legacy system for each disease? If so, can you share an example of the output?

Answer: The State is in the process of compiling the list of questions from the legacy system for each disease. This information will be made available to the selected vendor during the Design, Development, and Implementation (DDI) phase. Any shared outputs will align with the State’s data governance policies and security requirements.

32. The RFP states that approximately seven years of historical data will be migrated.

Can the State provide estimated record counts by category (e.g., events, lab results, case records)?

Answer: The DOH generally anticipates the records retention back 7 years. There are potentially additional years required for aggregate data analysis, historical review, trending, and program reporting requirements. Offerors should refer to the RTM for TR124, copied below:

Offeror to describe in detail the proposed data migration strategy. Data migration involves approximately 7 years of historical Surveillance data containing an estimated historical volume of: 7,200,000 Event records, 3,000,000 Person records, 10,000,000 Lab Result records, and a current estimate of 250 active Users.

33. The State has outlined that it will assist in cleaning data based on vendor instructions.

Will there be dedicated State personnel assigned for this task?

Answer: Yes, the DOH plans to assign dedicated personnel supporting data cleaning and ETL.

The DOH expect this to be based on the Offeror team primarily performing data migration activities. The level of support and personnel allocation will depend on the scope and complexity of the data migration process. Offerors should outline their data migration activities, including roles, responsibilities, and expected level of effort, to ensure proper resource planning and coordination with the support of State personnel.

34. The RFP mentions user-configurable workflows. Can the State provide a list of expected user roles and permissions across different departments?

Answer: The expected user roles span across multiple DOH divisions and external provider users, including but not limited to:

• DOH Staff: Disease investigators and epidemiologists.

• DOH Staff Supervisors: Program managers, working supervisors.

• Providers & External Partners: Healthcare facilities, laboratories, and public health stakeholders.

• IT & System Administrators: Responsible for managing system configurations, access permissions, and security.

The DOH additionally expects roles and permissions to permit access limitations for certain sensitive disease conditions. The workflows, forms, and patient data associated with sensitive conditions not limited to STD, HIV, and others.

48. RFP Attachment E RTM, Business Regs, R9 - RFP Language: Support development of system tools to assist case managers in tracking and managing clients effectively, including reports on services provided, outcomes, and reasons for service gaps.

Question: Will the State provide a use case for this requirement?

Answer: The DOH anticipates case managers must track client progress, outcomes, and trends within the system. This is a core EDSS requirement for any of the reportable diseases in the system.

50. RFP Attachment E RTM, Business Regs Tab - RFP Language: Support the ability to generate ad hoc reports for CDC NTSS and internal variance reports with flexibility to run real-time queries. Question: This requirement seems to be a duplicate of R90. Will the state remove requirement in row 92 does not indicate an item number and does not indicate a Priority category.

Answer: The requirement to support ad hoc reporting for CDC NTSS and internal variance reports with flexibility to run real-time queries appears in both row 92 and 98. Since row 98 explicitly categorizes this functionality as essential, it takes precedence.

Offerors should ensure their solutions provide the necessary real-time query and reporting capabilities as specified in Business Requirements R90. This is duplicated on both Excel row 92 (no requirement number) and Excel row 98 (R90). Offerors are requested to skip row 92.

51. RFP Attachment E RTM, Business Regs, R134 - RFP Language: Integrate and configure EDSS-associated data in data management tools (e.g., DOH existing instances of Collibra DIC, Collibra Data Quality) for data catalog and data quality improvement, in order to enhance the ability for DOH to use data. Question: What is the Priority category for this requirement?

Answer: The requirement R134, to "Integrate and configure EDSS-associated data in data management tools (e.g., DOH existing instances of Collibra DIC, Collibra Data Quality) for data catalog and data quality improvement", is classified as Core. The State will review and update any discrepancies through an amendment if necessary, and Offerors should align their proposals accordingly.

53. RFP Attachment E RTM - RFP Language: Offeror to describe in detail the solution's ability to track and report on costs associated with provider/clinic visits, inclusive of assessments and services provided, for reimbursement purposes. Question: Please provide a use case and workflow for this requirement.

Answer: The DOH anticipates for an example disease there may be associated clinical assessments, visits, and testing that require reimbursement from non-insurance sources.

Tracking of these for reimbursement to certain classes of medical providers requires logging of these services and generation of a report.

Preproposal Conference Questions:

Question 59: Would the state be interested in a second round of questions based upon the turn around time of the RFP being released?

Answer: The procurement schedule allows for a single round of vendor questions, with responses provided by the State by the deadline specified in Section 1.1. While additional clarifications may be provided at the State’s discretion, the period for vendors to ask questions is now closed.

Question 62: If there is a solution available that meets the objectives in the State's Scope of Work that comes as part of a package of additional services and is offered as a comprehensive solution, would the State be interested in these additional services or is the State only seeking to contract for exactly what is specified and outlined in the Scope of Work?, Answer: The State is open to evaluating comprehensive solutions as long as they align with the EDSS modernization objectives and do not create excessive reliance on proprietary components that hinder interoperability with existing and future public health systems.

All other terms of the solicitation shall remain the same.

Amber L. Wright

Procurement Officer