Attachment E DOH Drafted EDSS RTM.xlsx
XLSX spreadsheet 110 KB Posted
- Solicitation number
- P25001422
- Issued by
- Honolulu County, Hawaii
About this file
This is a Requirements Traceability Matrix (RTM) document from the Hawaii Department of Health (DOH) for an Enterprise Disease Surveillance System (EDSS). The document outlines comprehensive technical, functional, and business requirements for a new EDSS platform that will modernize disease surveillance and case management capabilities. The system must support multiple disease programs, integrate with various external systems including labs and healthcare providers, and enable automated data exchange using modern standards like FHIR and HL7. Key requirements include case/event management, outbreak tracking, laboratory reporting integration, contact tracing, deduplication capabilities, and customizable workflows for different disease types.
The RTM is structured into sections covering enterprise architecture, general requirements, product support, technical/functional specifications, and business requirements. Notable technical requirements include SaaS/PaaS hosting with a strong preference for established platforms like Microsoft Azure, Amazon AWS, or Google GCP, FedRAMP/HITRUST certification, integration with the state's Active Directory, and support for a Master Patient Index (MPI). The system must meet CDC reporting requirements and support integration with DOH's existing tools including Rhapsody integration engine, Collibra Data Catalog, Power BI, and the Enterprise Data Warehouse. The document does not specify pricing terms, set-asides, or specific funding requirements.
View the file
Other files
Show all 14
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Instructions and Definition
| ATTACHMENT E - DOH Drafted EDSS RTM | |
| Definition of 'Type' | |
| Term | Definition |
| Functional | Impacts the Business Process Requirements that define features of the product that specifically satisfy a business need, or with which the program area will directly interact. |
| Technical | Impacts the Product Infrastructure Requirements that identify the technical constraints or define conditions under which the product must perform. |
| Business | Impacts Business Operations Requirements defined by the lines of business, scoping required functions necessary for operations. |
| Directions | |
| Offerors must provide a full response to each item number without cross referencing other sections of the proposal. Offerors must use the table format and maintain numbering provided by the STATE to respond to each item number. Attachments, documents, or samples must be clearly referenced where in the response they can be found in the applicable item number. Offerors may add brief notes for clarifications of how they propose to meet the requirement. |
A product must be delivered with all Core and a significant portion of Essential specifications represented, and with a plan to implement the remaining Essential specifications in the subsequent phase. Proposals delivering less than Core or Essential will not be rejected. All proposals will be evaluated according to what can be delivered based on the requirements of the STATE.
| Definition of 'Priority' | |
| Term | Definition |
| Core | Requirements that must be included in the solution; otherwise, it will be of no use to the solution. |
| Essential | Requirements for which a short-term work-around may be developed (or for which an old process can be used for a little while longer), but over the long run, the requirements must be implemented. |
| Desired | Requirements that are bells and whistles which may be valuable to certain constituencies; however, the product will function without the requirement. |
| Definition of 'Rating' | |
| Rating | Definition |
| OOTB | Functionality found within the base product and requires no customization or configuration. |
| Config | Functionality is in the base product, but requires configuration with no additional costs. |
| Code | Functionality requires customization. Provide an explanation as to the complexity of the customization and a cost estimate in the Response column. |
| No | Functionality is not in the system, and can not be added even with customization. |
&"Arial,Regular"Requirements Matrix Attachment &K0070C0#
Enterprise Arch Reqs
| ENTERPRISE / ARCHITECT SPECIFICATIONS | Offeror Responses. Note separate Word document format answering to all questions is acceptable for responses. |
| Architecture - IT Application Questions |
Proposals MUST include a response to all the IT Application Questions. The following section contains technical questions for this solution. The offeror MUST provide answers to each question in the attachment.
| No. | Enterprise IT Standards | |
| E1 | Hosting: The STATE will consider an Offeror-proposed SaaS or PaaS-hosting provider, with the environments and service under the STATE's license. The DOH has a strong preference for established existing hosting platforms with which the STATE already has a contractual relationship, not limited to Microsoft Azure, Amazon AWS, and Google GCP. Note the award of a contract for any alternative vendor-hosted solution will be contingent upon approval of a hosting exemption. | Offeror Response: |
| Architecture - IT Application Questions |
Proposals MUST include a response to all the IT Application Questions: E2 - E32. The following section contains technical questions for this solution. The offeror MUST provide answers to each question in the attachment.
| E2 | Offeror must describe in detail the architecture of the proposed solution and supporting infrastructure. | Offeror Response: |
| a. Include the technology stack, including the software products and programming language(s) used to create the solution platform | ||
| b. Include the network and infrastructure architecture, including security levels, connectivity points, and capacity | ||
| c. Include the storage architecture, including security controls (i.e. encryption at rest & in-transit) | ||
| d. Include related technical architectural diagrams (Noting the DOH's preferred high-level notional architecture in the RFP document). | ||
| e. Any load/performance testing products used and whether the solution provides a means for performance monitoring by the STATE. | ||
| f. Any secure code reviews as they pertain to the Software Development Life Cycle (SDLC) strategy. | ||
| E3 | Offeror must describe in detail the solution’s ability to integrate with other applications, APIs, or datasets, and other external dependencies. Such as, but not limited to: | Offeror Response: |
| a. Describe if the proposed solution allows for bi-directional integration using FHIR (HL7 Fast Healthcare Interoperability Resources) inclusive of FHIR APIs. | ||
| b. Describe the proposed solution capability to exchange HL7 2.5.1 messages specifically: | ||
| c. Describe the proposed solution's capability with additional HIE HL7 message types. | ||
| d. Describe the proposed solution's capability of integrating with non-health IT systems | ||
| E4 | Offeror must describe in detail the solution’s ability to scale as demands increase or decrease. To include: |
- Total Users:
- Concurrent Users:
- Total Data Volume:
- Executing Simple Queries
- Executing Complex Queries
- UI latency
- Notifications and Triggers
| - License model changes, if any for scaling up & down capacity | Offeror Response: | ||
| E5 | Offeror must describe in detail the solution’s network latency requirements, and approach to users ability to work offline (e.g., for disease investigators in the field), if any. | Offeror Response: |
E6 Offeror must describe the solution’s ability to provide high availability, and ability to meet the DOH's preferred SLA of 99.95% uptime on a 24x7x365 basis. Offeror Response:
E7 Offeror must describe the solution’s ability to be enhanced using technical and non-technical SME resources to implement changing technical and business requirements, inclusive of workflows and form templates. Offeror Response:
E8 Offeror must describe the solution’s ability or limitations for migrating solution elsewhere in the future with regard to either party terminating services. Offeror Response:
E9 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. Offeror Response:
| Authentication | ||
| E10 | Offeror must describe in detail how the proposed solution supports authenticating State users by integrating with the STATE’s Active Directory and/or Azure AD. | Offeror Response: |
E11 Offeror must describe in detail how the proposed solution integrates with Active Directory and/or Azure AD (password management, user provisioning, role based security). Offeror Response:
E12 Offeror must describe in detail the proposed solution’s ability to support mobile devices (Browser or Mobile app (Android and iOS)) Offeror Response:
E13 Offeror must describe in detail how the proposed solution supports authenticating external users by integrating with the STATE’s Azure B2C federated identity provider service via OpenID Connect or SAML if a vendor hosted solution is offered. Offeror Response:
E14 Offeror must describe in detail how the proposed solution supports MFA. Offeror Response:
| Data | ||
| E15 | Offeror must describe in detail the options available to migrate or extract the data to another application or storage system, including API, SQL Interfaces, Batch Export format, etc. also include file formats, data migration requirements, encryption, specific products required, etc. Note the DOH strongly prefers FHIR API as the primary mechanism for most future interfaces whenever possible, for TEFCA compliance. | Offeror Response: |
E15 Offeror must describe in detail the proposed solution’s EDSS data migration strategy, and how the Offeror plans to migrate information from both the legacy Maven platform and other legacy source systems. This description must include the Offeror's proposed strategy for data migration using the DOH's Enterprise Data Warehouse as a repository. Offeror Response:
E16 Offeror must describe in detail the proposed solution’s EDSS data dictionary, and how the Offeror plans to configure and leverage this data model in operations using the DOH's existing Collibra Data Catalog tool. This description must include the Offeror's proposed strategy for managing integration of numerous legacy data models from the EDSS divisions and offices. Offeror Response:
E17 Offeror must describe in detail the proposed solution’s EDSS data quality strategy, and how the Offeror plans to configure data quality in operations using the DOH's existing Collibra Data Quality tool. Offeror Response:
E18 Offeror must describe the controls used to ensure data is properly classified and how sensitive/confidential data is safeguarded. Offeror Response:
E19 Offeror must describe the practices and procedures used to provide Electronic Discovery of specific records or data, and any legal positions regarding subpoenas, jurisdiction and potential confiscation of data. Offeror Response:
E20 Offeror must describe in detail the proposed solution’s new Master Patient Index (MPI) tool, subcontractor(s) providing this COTS tool, and how the Offeror plans to configure the MPI. Offeror Response:
E21 Offeror must describe the practices and procedures used to provide MPI functionality, inclusive of practices for identifying patient matches (both automated and manual exceptions), merging, and unmerging of records. Offeror Response:
| Security | ||
| E22 | Offeror must describe if the proposed solution is FedRAMP, HITRUST, or StateRAMP certified, or any certification of the platform. Proposed solution is described as the solution provided by Offeror, NOT the 3rd party hosting environment (e.g. Azure/AWS/GCP). | Offeror Response: |
E23 Offeror must describe the controls used to measure and meet regulatory requirements and certifications. Include any Application Scanning reports, Vulnerability Scanning reports, and Penetration Testing reports. Include schedules for recurring/updated reports. Offeror Response:
E24 Offeror must describe the controls used to manage operational logs for troubleshooting and regulatory compliance. Offeror Response:
E25 Offeror must describe in detail the controls used to ensure that privileged users cannot perform unauthorized or unlawful activities. Include any options for the STATE to run application security scanning software against the hosted solution. Offeror Response:
E26 Offeror must describe in detail the proposed solution’s Record Level Audit tracking. Offeror Response:
| SaaS or PaaS / Non-State Hosted | ||
| E27 | Offeror must describe in detail the preferred hosting details. The EDSS system must be maintained in a SaaS or PaaS hosting service, with all data and environments accessible to DOH staff in State-licensed environments. The Offeror must describe in detail the proposed hosting and environments. Note the State strongly prefers a SaaS hosted platform for which there is already a STATE hosting agreement such as with Microsoft Azure, Amazon AWS, or Google GCP. | Offeror Response: |
| a. The SaaS or PaaS hosting service | ||
| b. The partner relationship of Offeror to the service provider | ||
| c. The proposed hosting and environments details, inclusive of all components (e.g., with MPI) | ||
| E28 | Offeror must describe the data center operational controls and policies, and provide any relevant audit reports, including Statement on Standards for Attestation Engagements (SSAE) Service Organization Control (SOC) 2 Type II audit or equivalent such as ISO 27001 for the primary vendor and any 3rd party providers/partners such as cloud service providers. Include any options for the STATE to access the vendor datacenter(s). Include any “Right to Audit” clauses available to the STATE. | Offeror Response: |
E29 Offeror must describe the backup procedures, including off-site storage, encryption, and the frequency of restore testing. Offeror Response:
E30 Offeror must describe the practices and procedures used to manage/monitor data retention schedules and the purging or archival of data when retention schedules are met. Offeror Response:
E31 Offeror must describe any options for the STATE to run application security scanning software against the hosted solution. Offeror Response:
E32 Offeror must describe the controls, tools, and procedures in place to handle natural disasters and maintain business continuity. Include the Recovery Point Objective (RPO) and Recovery Time Objective (RTO). Offeror Response:
Page &P of &N
General Reqs
| GENERAL REQUIREMENTS | Offeror Responses. Note separate Word document format answering to all questions is acceptable for responses. | |
| No. | Licensing Requirements: |
The contractor will provide the STATE with all applicable licenses related to the proposed solution.
G1 Software Licensing: Offeror must describe in detail all licensing required and licensing options for the proposed solution, including what is covered under each licensing option and advantages of the various options. Offeror Response:
G2 Offeror must describe in detail the process to add licensing throughout the term of the contract. Offeror Response:
G3 Offeror must describe if any additional licenses purchased during the term of the contract can be co-termed with the other licenses. Offeror Response:
| Location of Work - Travel: | ||
| G4 | No on-site work is required. Please confirm. | Offeror Response: |
| State Services: | ||
| G5 | The STATE will provide a sponsor and a primary project manager, a business analyst and subject matter experts. Please confirm you understand. | Offeror Response: |
| Risk Management and Safety | ||
| G6 | Describe any risks you feel could impact a timely and fully successful completion of the project. Describe what measures will be taken to avoid or minimize these risks. Identify any additional measures the STATE can take to mitigate these risks. | Offeror Response: |
Project Management Requirements Project Management for the awarded contract will be done following the state Project Management methodology as described in standard STD009-005.
| G7 | ITD Project Management Tools and Templates, Project Management | | |
| The project shall follow the Project Management Institute’s (PMI) Project Management Body of Knowledge (PMBOK). | ||
| The State’s project manager will prepare a Project Management Plan using a defined methodology and applicable template for Project Management. The contractor will need to provide information necessary to prepare the plan. | ||
| The State’s project manager will direct and manage the project on a day-to-day basis and will have the primary responsibility for management of the project. The contractor’s project manager and lead consultants will report to the State’s project manager within the project’s governance structure. | ||
| Contractor shall be responsible for the project management related tasks/information specified below. | ||
| Contractor Primary Responsibilities: | ||
| 1. Provide a Quality Management Plan to include the methodology for maintaining quality of the code and workmanship, and related subcontractor(s) activities where appropriate. | ||
| 2. Provide a Test Management Plan which describes how the contractor, and the STATE shall verify the product meets the requirements. | ||
| Contractor Secondary Responsibilities: | ||
| 1. Collaborate in the development of detailed schedule with fixed deadlines to include: | ||
| a. A work breakdown structure; | ||
| b. Schedule including tasks, activities, activity duration, sequencing and dependencies; | ||
| c. Completion date of each task; | ||
| d. Milestones; including entrance and exit criteria for specific milestones; | ||
| 2. Collaborate in the development of the Human Resources Plan to include: | ||
| a. Staff assigned and their location and schedule; | ||
| b. The project resources required; | ||
| c. Resource allocation percentage by role; | ||
| d. Contractor’s resources; | ||
| e. State’s resources. | ||
| 3. Collaborate in the development of a Communication Plan including: a plan for generation, documentation, storage, transmission and disposal of project information. | ||
| 4. Collaborate in and review of the Risk Management Plan to ensure that risks are identified, planned for, analyzed, communicated and acted upon effectively. | ||
| 5. Collaborate in the development of the Training Plan. | ||
| 6. Collaborate in the development of the Implementation Plan. | ||
| 7. Collaborate in the development of the (Organizational) Change Management Plan. | ||
| 8. Collaborate in the development of the Transition Plan. This plan shall describe the steps necessary to turn the final deliverables over to the STATE. The plan shall contain sufficient information to assure that all necessary steps are identified and that each step has sufficient resources assigned. | ||
| 9. Collaborate in the development of the Project Closeout Report to include participation in the lessons learned exercise. | ||
| Describe your strategy for accomplishing the Project Management requirements. Provide examples of project management methodologies, tools, and templates used in previous projects that support offeror’s ability to function successfully within Hawaii project management framework, including your work breakdown structure and schedule. | Offeror Response: |
Contract Deliverables and Estimated Schedule Requirements The STATE has identified the following deliverables which are significant work products or milestones in the project. The STATE requests these deliverables be addressed in the Contract Schedule, at a minimum. The following deliverables may be modified based on contractor’s implementation strategy.
The contractor shall develop an estimated schedule for accomplishing the Scope of Work, including these specific deliverables including those associated with the methodology employed on the project. The STATE and contractor will agree upon expectations and acceptance criteria for deliverables.
Upon award, the successful offeror’s proposed project schedule will be reviewed and refined during the planning phase.
| G8 | 1. Project ‘Kick Off’ Meeting |
| 2. Planning | |
| 3. Application Configuration | |
| 4. Interfaces | |
| 5. Installation | |
| 6. System Setup/Configuration | |
| 7. Testing | |
| 8. Training | |
| 9. System Documentation | |
| 10. Implementation | |
| 11. Final Acceptance | |
| Offeror must submit a draft schedule that addresses the deliverables and milestones specifically described in the Scope of Work. The proposed schedule may incorporate other deliverables, work products, milestones, or work breakdown that the offeror feels are significant in the project. |
The draft work schedule will cover both offeror and the STATE tasks and responsibilities. Describe any expectations from the STATE related to each deliverable or milestone.
| The draft schedule must contain: | Offeror Response: | |
| 1. Description of the work/project | ||
| 2. The number of STATE staff required to perform work in proposed schedule. | ||
| 3. Expectations of Contractor | ||
| 4. Expectations of State | ||
| 5. Completion Date - Timeline | ||
| 6. Deliverables - SOW with Acceptance Criteria |
G9 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. Provide a narrative describing the personnel that will perform the work and methods to be used Offeror Response:
| Value-Added Features | ||
| G10 | The proposed solution may include value-added features. Value-added features include any functionality, products, services, optional modules, or upgrades that are not part of the IT requirements in this RFP. Describe any additional functionality, products, optional modules, upgrades or services that you offer and are not a part of the RFP requirements that you believe would add value to your proposed work on this project. | Offeror Response: |
| 1. Offeror shall list the cost of value-added features separately in the cost proposal. | ||
| 2. The STATE shall not consider these costs as part of cost evaluation scoring. | ||
| 3. The STATE reserves the right to include value-added features from the proposals during contract negotiations. |
Page &P of &N http://www.pmi.org/ Prod Support Reqs
| PRODUCT SUPPORT, CUSTOMER SERVICE, EXPERIENCE AND QUALIFICATION REQUIREMENTS | Offeror Responses. Note separate Word document format answering to all questions is acceptable for responses. | |
| No. | Warranty |
CONTRACTOR must provide a minimum 365-day warranty for the proposed solution. The Contract includes provisions related to warranties. The STATE will consider options for additional warranty coverage. All costs associated with warranties must be clearly outlined in the cost proposal. Describe the following:
P1 What is the hypercare and warranty period and what is covered under the warranty? Offeror Response:
P2 Describe any differences between warranty benefits and software maintenance benefits. Offeror Response:
P3 Provide the warranty language that the proposal suggests for incorporation into the Contract. Offeror Response:
P4 Provide any warranty exclusions. Offeror Response:
P5 All costs associated with warranties must be clearly outlined in the cost proposal. Offeror Response:
Software Maintenance The STATE requires contractor to provide software maintenance support. Describe in detail how software maintenance is handled.
P6 Offeror must describe in detail how software maintenance is handled. Offeror Response:
P7 Offeror must describe in detail when the STATE will be required to pay for maintenance prior to first production use and the maintenance payment process. Offeror Response:
P8 Offeror must describe in detail the upgrades and technical support that is included with the software maintenance. Offeror Response:
P9 Offeror must describe in detail any software maintenance requirements. Offeror Response:
P10 Offeror must describe in detail the process for issuing maintenance releases and patches. Offeror Response:
P11 Offeror must describe in detail your major and minor release cycles. Offeror Response:
P12 Offeror must describe in detail the frequency for major and minor upgrades. Offeror Response:
P13 Offeror must describe in detail the typical down time required for major and minor upgrades. Offeror Response:
P14 Offeror must describe in detail the estimated level-of-effort required to perform an upgrade. Offeror Response:
P15 Offeror must describe in detail the process for upgrading and applying patches to solution. Offeror Response:
P16 Offeror must describe in detail if database schema extension is required to meet the business need, how does this impact the upgrades/patches. Offeror Response:
P17 Offeror must describe in detail how are the customizations or configurations maintained during an upgrade. Offeror Response:
P18 Offeror must describe how new features are introduced and prioritized. Offeror Response:
| P19 | Maintenance Procedures | |
| Offeror must describe in detail their procedure for providing planned and unplanned maintenance service (to be approved by the STATE) that would include: | Offeror Response: | |
| a. Help Desk, | ||
| b. Trouble reporting procedures, | ||
| c. Telephone numbers for voice, | ||
| d. E-mail addresses, | ||
| e. Maintenance procedures | ||
| 1. Critical | ||
| 2. Non-Critical | ||
| f. Outage notification process | ||
| g. Escalation procedures. | ||
| All listed personnel shall include their telephone numbers and e-mail addresses. | ||
| P20 | Offerors must describe in detail the service level agreements for the proposed solution. | Offeror Response: |
P21 Offerors must describe their process for issuing credits to the STATE if a service level would not be met. Offeror Response:
| Technical Support | ||
| P22 | Is documentation available for the system administrator and support for end users (i.e. online knowledge base help and user’s manuals, etc.)? Please explain | Offeror Response: |
P23 Is your support staff located at a call center? If so, where Offeror Response:
P24 If the proposed solution provides a public facing portal, describe support options for Public Users (i.e. password reset, creating a family unit, etc.) Offeror Response:
P25 Describe if you meet the response times listed in the Technology Contract – Attachment C, Exhibit C. Do you offer anything above those listed? Offeror Response:
P26 Provide help desk employees' qualifications. Offeror Response:
| Customer Service and Support | ||
| P27 | Offeror must describe in detail the following: | Offeror Response: |
| a. Provide resumes of the customer service and support representatives that will support the STATE. Detail their experience with the products and services being offered. | ||
| b. Offeror’s process for handling customer inquiries and response time. | ||
| c. Ongoing product updates and strategic planning. | ||
| d. Provide data on response and resolution time. | ||
| e. Reports related to technical support performance under the contract. Provide data on response and resolution time. | ||
| f. Initial training and start-up services. | ||
| g. Ongoing training programs. | ||
| P28 | Offeror must provide information on the point of contact for questions relating to the proposal: | Offeror Response: |
| a. name, | ||
| b. title, | ||
| c. phone number, | ||
| d. e-mail address | ||
| P29 | Offeror must provide a narrative of the dedicated contract representative and include: | Offeror Response: |
| a. name, | ||
| b. title, | ||
| c. phone number, | ||
| d. e-mail address | ||
| P30 | Offeror must describe in detail how they will provide training to the different roles/groups. | Offeror Response: |
| Prior Experience | ||
| P31 | Describe the number of years the offeror has provided the type of work requested in this RFP. Describe specific experience of their firm in completing similar projects. Provide a description of the project, approximate time frame of the project, and contact information for the customer. | Offeror Response: |
| P32 | The ideal Offeror would meet the following experience and qualification requirements: | Offeror Response: |
| a. The ideal solution would be a Commercial off-the-shelf solution or Software-as-a-Service (SaaS) that is commercially available and has been successfully implemented for a minimum of three (3) customers and satisfactorily performing for at least six months. Describe / provide information to support this. | ||
| b. The ideal Offeror would have performed similar work for a comparably sized government entity or Public Health Department within the previous two (2) years. Provide / describe information to support this. | ||
| P33 | Describe specific experience of their firm in completing similar projects. Provide a description of the project, approximate time frame of the project, and contact information for the customer. | Offeror Response: |
| P34 | The Offeror must provide the following general background information: | Offeror Response: |
| a. Name, address, telephone number, and e-mail address of the Offeror including all d/b/a’s or assumed names or other operating names of the Offeror and any local addresses and phone numbers. | ||
| b. Number of years in business. | ||
| c. Number of employees in the business. | ||
| d. The location(s) including address and telephone numbers of the offices and other facilities that relate to the Offeror’s performance under the terms of this RFP | ||
| e. Describe the size of your organization; | ||
| Project Team | ||
| P35 | Provide a narrative or organizational chart that describes the organization of the proposed project team. Provide information for key project team members (Project Manager, Architect, Main Business Analysis, Lead Developer, etc.), including: | Offeror Response: |
| a. Description of anticipated work they will perform and approximate estimated hours; | ||
| b. Resume or description of the relevant education, training, experience, skills and qualifications; | ||
| c. If the offeror needs to hire for this project, identify the job descriptions and number of staff members to be recruited; | ||
| d. Subcontractors. If an offeror intends to use subcontractors, the offeror must identify in the proposal the names of the subcontractors and the portions of the work the subcontractors will perform. Provide a statement that the offeror will ensure that the subcontractor has or will obtain any required licenses and registrations, including registration with the Hawaii Secretary of State; and | ||
| P36 | The Offeror must provide resumes for all key personnel (Project Manager, Architect, Main Business Analysis, Lead Developer, etc.) of the Offeror who will be involved in providing the goods and/or services contemplated by this RFP. The personnel listed must be the people that will perform/provide goods and services for the STATE. The following information must be included in the resumes: | Offeror Response: |
| a. Full name, | ||
| b. Role, | ||
| c. Education including degrees, relevant certifications (include certification number), and the institution from which they were obtained, | ||
| d. Years of experience and employment history particularly as it relates to the requirements of the RFP, | ||
| e. Description of the type of work the individual shall perform, | ||
| f. A detailed description of relative experience in the items listed in this RFP. | ||
| P37 | Offeror must provide a designated executive level contact that will act as a point of contact for any issues that need escalation or to discuss the needs of the STATE. This point of contact will be required to participate in any requested demonstration or presentation requested during the RFP process. They will discuss how the contract will be supported and how the Offeror and STATE will work together to ensure a successful outcome. | Offeror Response: |
| P38 | If the Offeror is proposing any subcontractors, Offeror must provide resumes for all subcontractors who will be involved in providing the goods and/or services contemplated by this RFP. The personnel listed must be the people that will perform/provide goods and services for the STATE. The following information must be included in the resumes: | Offeror Response: |
| a. Company Name, | ||
| b. Full name, | ||
| c. Role, | ||
| d. Education including degrees, relevant certifications, and the institution from which they were obtained, | ||
| e. Years of experience and employment history particularly as it relates to the requirements of the RFP, | ||
| f. Description of the type of work the individual shall perform, | ||
| g. A detailed description of relative experience in the items listed in this RFP. | ||
| P39 | Subcontractor. If submitting a proposal with subcontractors, offeror must submit a copy of the subcontractor agreement that identifies the parties involved and its rights and responsibilities regarding performance and payment. | Offeror Response: |
| References | ||
| P40 | Provide three (3) references for similar (government) projects the offeror has completed. Offerors must include: | |
| • | the name of a contact person, | |
| • | address, | |
| • | email, and | |
| • | telephone number. |
| Offerors are instructed to notify the reference that the STATE will be contacting them by email or phone. Evaluation will be impacted if the STATE is unable to contact the reference or the reference does not timely provide the requested information. | Offeror Response: | |
| Reference 1 | ||
| Reference 2 | ||
| Reference 3 |
&18Page &P of &N
Tech&Func Reqs
| Technical and Functional Requirements | |
| No. | Offerors must provide a full response to each item number without cross referencing other sections of the proposal. Offerors must use the table format and maintain numbering provided by the STATE to respond to each item number. Attachments, documents, or samples must be clearly referenced where in the response they can be found in the applicable item number. Offerors must provide a rating of OOTB, Config, Coding, or No (refer to Definitions tab) for each priority. |
| A product must be delivered with all Core and a significant portion of Essential specifications represented, and with a plan to implement the remaining Essential specifications in the subsequent phase. Proposals delivering less than Core or Essential will not be rejected. All proposals will be evaluated according to what can be delivered based on the requirements of the STATE. | DOH Priority (Essential, Core, Optional) | Rating: | |
| (available responses: OOTB, Config, Coding, No) | Response Notes | ||
| CASE / EVENT MANAGEMENT | |||
| TR1 | Offeror to describe in detail how case information is collected and entered into the system. This solution must support multiple methods (Form and survey responses, eCR, ELR, API, batch processing, file import, etc.). | Core | |
| TR2 | Offeror to describe in detail how all case information is easily displayed in the solution. Data must include interview responses, lab data, survey responses, classification decisions, vaccination records, etc. | Core | |
| TR3 | Offeror to describe in detail how solution shall produce case information summary views to display key case information at a glance. These shall be configurable by disease case type and user role. | Core | |
| TR4 | Offeror to describe in detail how solution shall support the ability to flag a case as high priority or for user review in configurable queues. (ex. Missing data fields, multi-drug resistant contact, etc.) | Core | |
| TR5 | Offeror to describe in detail how cases shall be linked to an outbreak event. Solution must support the ability for a single case to be linked to multiple outbreaks. | Core | |
| TR6 | Offeror to describe in detail the solution's ability to suggest outbreaks a case could be linked to based on system-generated, or pre-defined business logic. | Core | |
| TR7 | Offeror to describe in detail the solution's ability to support bulk linkages of cases to an outbreak. | Essential | |
| TR8 | Offeror to describe in detail how cases can be linked to other cases. The ideal solution to support multiple methods (form logic, case search, import, etc.) | Core | |
| TR9 | Offeror to describe in detail the solution's ability to indicate and display the type of linkage/connection between cases. | Core | |
| TR10 | Offeror to describe in detail the solution's ability to create and manage a list of exposure sites with associated addresses and other metadata. | Core | |
| TR11 | Offeror to describe in detail how exposure sites are linked to a case. | Core | |
| TR12 | Offeror to describe in detail the solution's ability for users to input notes on disease-specific forms on a case. | Core | |
| TR13 | Offeror to describe in detail the solution's ability to automatically retrieve and display vaccination data via HL7/FHIR API call from Hawaii's Immunization Information System (HI-IIS). | Core | |
| TR14 | Offeror to describe in detail the solution's ability to support an organization, location, or animal as the primary participant for a case, instead of a person record. | Core | |
| TR15 | Offeror to describe in detail the solution's ability to create a case with a de-identified or missing primary participant, as well as add a primary participant at a later date. | Core | |
| TR16 | Offeror to describe in detail the solution's ability for users to create and send forms and surveys to supplement case, person, and outbreak record information, tied to specific case definitions. | Core | |
| TR17 | Offeror to describe in detail the solution's ability for users to custom-configure form and survey types, form and survey fields, disease and location-specific workflows, automated business rules, and scheduling. | Essential | |
| TR18 | Offeror to describe in detail the solution's ability for users to custom-configure form and survey fields, workflows and process steps, depending on clinical needs, and tied into each of the specific disease case definitions (e.g., Covid19, tuberculosis, HIV, or H5N1, etc.) | Essential | |
| TR19 | Offeror to describe in detail the solution's ability to create and manage a single master list of statewide healthcare provider facility names, associated addresses, provider specialties, capacity, and other associated metadata (e.g., Master Provider Directory or "MPD".) | Core | |
| TR20 | Offeror to describe in detail the solution's ability to manage a single master list of statewide healthcare provider facilities ("MPD") based on data ingested from multiple interfaces, and automate data management and provider data deduplication inclusive of data quality-handling. This shall permit a minimum of 90% of provider data ingest to be automated, with processes for manual exception handling by DOH staff. | Core | |
| TR21 | Offeror to describe in detail the solution's ability for providers to be linked to a case for tracking provider visits, follow-ups, and care received. | Essential | |
| TR22 | 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. | Essential | |
| TR23 | Offeror to describe in detail the solution's ability to assign cases/events to investigators both individually and in bulk. This is required for assignment both manually and automatically based on predefined case characteristics and simple business rules. | Core | |
| TR24 | Offeror to describe in detail the solution's ability for multiple investigators to be assigned to a single patient case and disease case event. | Core | |
| TR25 | Offeror to describe in detail the solution's ability to auto-classify cases using configurable business rules. | Core | |
| TR26 | Offeror to describe in detail the solution's ability for case investigators to manually classify cases, including the ability to bulk classify cases by multiple factors inclusive of but not limited to disease types and patient locations. | Core | |
| TR27 | Offeror to describe in detail the solution's ability for users to track cases as they move through workflow steps and classification stages. | Core | |
| TR28 | Offeror to describe in detail the solution's ability to support development and customization of personalized care plans based on the patient's history, diagnoses/disease conditions, preferences, goals, and other factors. | Essential | |
| TR29 | Offeror to describe in detail the solution's ability to track patient and case progress over time and adjust treatment regimens or care plans to optimize outcomes. | Essential | |
| TR30 | Offeror to describe in detail the solution's ability to perform patient matching, based on an MPI, and detect and display to the user when multiple concurrent diseases are present within an individual unique patient. | Essential | |
| TR31 | Offeror to describe in detail the solution's ability to function as a patient-focused (e.g., one unique patient with multiple associated diseases) case management system or Electronic Health Record (EHR) equivalent. | Essential | |
| TR32 | Offeror to describe in detail the solution's ability to segment or restrict access to cases for management depending on disease type (e.g., for sensitive health conditions such as HIV/AIDS.) | Core | |
| TR33 | Offeror to describe in detail the solution's contact tracing capabilities, and configurable workflows for multiple disease conditions. | Core | |
| TR34 | Offeror to describe in detail the solution's out-of-the-box case/event types for which there are pre-defined templates, and the ability to meet the entire CDC-defined list of nationally-notifiable disease case definitions | Core | |
| TR35 | Offeror to describe in detail which of the solution's out-of-the-box case/event type templates have options for paper print document export capabilities. | Desired | |
| TR36 | Offeror to describe in detail how the solution's out-of-the-box case/event type templates have digital document export capabilities via export to multiple methods, including integrated email sending (e.g., via Outlook integration). | Core | |
| TR37 | Offeror to describe in detail the solution’s ability to allow for an app on user devices (e.g., laptop, tablet, smartphone) running a local offline in offline mode to fill and send/receive disease case forms, templates, processes, and workflow steps, without the need for internet connection; the functionality shall allow seamless updates to the system as soon as the user is back online. | Core | |
| TR38 | Offeror to describe in detail the solution's ability to notify DOH program areas of a closed case event and display closed events on dashboards configured by user type and role. | Core | |
| TR39 | Offeror to describe in detail the solution's ability to assign cases and control case visibility and restrictions, via permission levels within the system | Core | |
| TR40 | Offeror to describe in detail how a unique person record can be linked to a case. The solution shall support multiple methods (existing person search, file import, new person record creation), and be based on use of a single Master Person Index component for a combination of probabilistic and deterministic matching. | Core | |
| TR41 | Offeror to describe in detail the solution's ability to simply create, update, and publish disease case definitions, as a non-technical user. | Core | |
| TR42 | Offeror to describe in detail the solution's ability to simply create, and update disease case investigation reports and dashboards specific to each defined disease case type. | Core | |
| TR43 | Offeror to describe in detail the solution's ability to generate, auto-update, and maintain configurable EDSS system alerts specific to each defined disease case type. | Core | |
| TR44 | Offeror to describe in detail the solution's ability to simply create, update, and publish disease case investigation forms, as a non-technical user. | Core | |
| TR45 | Offeror to describe in detail the solution's ability to create, manage, and update branching logic from disease case investigation forms. | Core | |
| TR46 | Offeror to describe in detail the proposed solution’s ability to capture digital signatures entirely within the system, inclusive of audit logs, aligned to the State's law permitting electronic signatures. | Desired | |
| OUTBREAK MANAGEMENT | |||
| TR47 | Offeror to describe in detail how new outbreak events are created. | Core | |
| TR48 | Offeror to describe in detail how new disease types or case definitions are created, aligned to evolving new CDC/State disease definitions. | Core | |
| TR49 | Offeror to describe in detail the solution's ability to classify an outbreak. | Core | |
| TR50 | Offeror to describe in detail the solution's ability to link and unlink all system objects (Case/Event, Person, Exposure sites, animals, locations, etc.) to an outbreak. | Core | |
| TR51 | Offeror to describe in detail the solution's ability to generate a summary of key outbreak metrics and related case information. Summary should be accessible in-app and electronically exportable in various file formats. | Essential | |
| TR52 | Offeror to describe in detail the solution's ability for non-admin users to generate unique forms/surveys for a specific outbreak. Survey/Form to be shown on each case linked to that outbreak. | Core | |
| TR53 | Offeror to describe in detail the solution's ability to create outbreak alerts according to State specifications and logic. | Desired | |
| TR54 | Offeror to describe in detail the solution's ability for a user to assign lead investigators, and change these assignments over time for an outbreak. | Core | |
| TR55 | Offeror to describe in detail the solution's ability for users to collect notes, inclusive of time stamps, on an outbreak. | Core | |
| PERSON MANAGEMENT | |||
| TR56 | Offeror to describe in detail the solution's ability to link a person record to a case. Solution to support multiple methods (Create new person record, search for existing, file import, etc.) | Core | |
| TR57 | Offeror to describe in detail the solution's ability to support and display a single person record linked to multiple cases. | Core | |
| TR58 | Offeror to describe in detail the solution's ability to gather demographic information (Name, DOB, gender, race/ethnicity, etc.) and attach it to a person record. Solution to support multiple methods (Manual entry, eCR, ELR, form response, file upload, etc.). | Core | |
| TR59 | Offeror to describe in detail the solution's ability to handle person record changes and allow (or not allow) the change to carry over to additional cases/events. (Ex: Address change, Sexual Orientation) | Core | |
| TR60 | Offeror to describe in detail the solution's ability to leverage a COTS Master Patient Index ("MPI") or Master Data Management ("MDM") tool, to perform automated patient matching and unmatching due to match errors, from all available EDSS-connected data sources, for a single patient view for a comprehensive deduplicated patient registry. | Core | |
| TR61 | Offeror to describe in detail the ability to provide and configure an integrated component of an MDM or MPI tool. This shall be an Offeror-supplied and configured component, and shall incorporate data from the EDSS and outside data sources for matching. | Essential | |
| TR62 | Offeror to describe in detail the solution's ability for a person record to be linked to another person record. | Core | |
| TR63 | Offeror to describe in detail the solution's ability for a person record to be linked to an outbreak. | Core | |
| TR64 | Offeror to describe in detail the solution's ability to display all lab results (across all cases) for an individual person record. | Core | |
| TR65 | Offeror to describe in detail the solution's ability to display all cases to which a person record is linked. | Core | |
| TR66 | Offeror to describe in detail the solution's ability to mark cases "sensitive" for sensitive health conditions. | Core | |
| TR67 | Offeror to describe in detail the solution's ability to restrict display of details on cases marked "sensitive" to which a person record is linked. | Core | |
| TR68 | Offeror to describe in detail the solution's ability for users to capture notes on a person record. | Core | |
| DE-DUPLICATION | |||
| TR69 | Offeror to describe in detail the solution's out of the box case & person record automated de-duplication functionality using an MPI or MDM tool. | Core | |
| TR70 | Offeror to describe in detail the solution's ability to notify/flag duplicate records for manual action by users, and to improve the MPI or MDM tool operation to improve duplicate detection processes. | Core | |
| TR71 | Offeror to describe how the solution's de-duplication functionality prevents duplicate records from being created. Describe how this functionality works when a user doesn't have access to the existing, potential duplicate record. | Core | |
| TR72 | Offeror to describe in detail solution's ability to revert merged/de-duplicated records. | Core | |
| TR73 | Offeror to describe in detail the solution's ability to prevent continuous flagging of records for possible duplication if they've already been reviewed and deemed to be "not a duplicate". | Essential | |
| TR74 | Offeror to describe in detail solution's ability to mass merge records through file import in multiple formats, from legacy data sources and via interfaces from outside systems. | Desired | |
| TR75 | Offeror to describe in detail the solution's ability to set criteria/thresholds which require manual user intervention before automatically merging records. | Core | |
| TR76 | Offeror to describe in detail the solution's ability for users to view records simultaneously (side-by-side) when making a decision to merge records. | Core | |
| TR77 | Offeror to describe in detail the solution's ability for users to select which fields are merged from all available person fields, when both automatically and manually de-duplicating records. | Core | |
| TR78 | Offeror to describe in detail how the solution manages potential duplicate records identified from external systems. | Essential | |
| LAB REPORTING (ELR), CASE REPORTING (eCR), ADT MESSAGES | |||
| TR79 | Offeror to describe in detail the solution's ability to ingest ELR, ADT and eCR messages and update data on a case/event. Shall include the ability to add/append data without replacing original value or duplicating an existing entry. | Core | |
| TR80 | Offeror to describe in detail the solution's ability to send/receive multiple ELR, ADT and eCR message formats (i.e. HL7 2.3.z, HL7 2.5.1, FHIR, CDA). | Core | |
| TR81 | Offeror to describe in detail the solution's ability to send/receive messages in FHIR format, aligned to federal TEFCA standards | Core | |
| TR82 | Offeror to describe in detail solution's ability to receive original and append corrected ELR messages from labs. | Essential | |
| TR83 | Offeror to describe in detail the solution's ability to receive and process animal ELR messages (ex. Rabies). | Desired | |
| TR84 | Offeror to describe in detail the solution's ability for users to customize which fields the system receives/processes within ELR, ADT and eCR messages. | Core | |
| TR85 | Offeror to describe the solution's ability to notify and generate reports for users when ELR, ADT and eCR import errors happen. | Core | |
| TR86 | Offeror to describe the solution's ability to resolve ELR, ADT and eCR import errors. | Core | |
| TR87 | Offeror to describe in detail the solution's ability to receive quantitative and qualitative results, as well as susceptibility, sequencing, genomic, other specialized electronic lab reports (ELR). | Core | |
| REPORTING / DATA EXPORT | |||
| TR88 | Offeror to describe in detail the solution's standard reporting capabilities. (define specifics) | Core | |
| TR89 | Offeror to describe the solution's ability to generate advanced reporting on ELR messages, including feed and data quality. | Desired | |
| TR90 | Offeror to describe the solution's file format options for data exports (ex. csv, Excel, SAS, etc.) | Core | |
| TR91 | Offeror to describe the solution's ability for users to generate both scheduled and ad-hoc reports, and ensure no overuse of system resources. | Core | |
| TR92 | Offeror to describe the solution's ability to use a reporting database to generate reports, in order to limit operational system impacts from transactional reporting. | Core | |
| TR93 | Offeror to describe in detail the solution's ability to make reports available for specified users based on their security/permissions. | Core | |
| TR94 | Offeror to describe in detail the solution's ability to generate and export letters or other formatted documents containing case details. | Core | |
| TR95 | Offeror to describe in detail the solution's scalable export functionality, including the ability to export all data, forms and metadata. | Core | |
| TR96 | Offeror to describe in detail the solution's ability to generate a summary report for a person/case/outbreak, etc. | Core | |
| TR97 | Offeror to describe in detail the solution's ability to include user-generated/custom fields in all reporting. | Core | |
| TR98 | Offeror to describe in detail the solution's ability to display configurable, interactive data visualizations. | Core |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .