9053_A1_HMIS Solution RFP.pdf
PDF 419 KB Posted
- Attached to
- HMIS Solution Request for Proposals
- Solicitation number
- S-91400-00016584
- Issued by
- Oregon
About this file
This Bid Amendment #1 modifies RFP #S-91400-00016584 for a Homeless Management Information System (HMIS) Solution for the Oregon Multi-Continuum of Care (OMC), which comprises four CoC jurisdictions (OR-502, OR-503, OR-504, OR-505). The amendment establishes a two-round competitive procurement process under ORS 279B.060 and OAR 137-047-0261. Round 1 determines shortlisted proposers based on technical qualifications, while Round 2 determines the award winner. Key dates include: questions due October 15, 2026; proposals due October 29, 2026; competitive range announcement approximately December 2, 2026; Round 2 requirements due December 8, 2027; Round 2 demonstrations scheduled December 7-10, 2026 or December 14-18, 2026; and Notice of Intent to Award approximately December 22-28, 2026. The RFP requires proposers to demonstrate a comprehensive HMIS solution supporting street outreach, day center services, emergency shelter, coordinated entry, rapid re-housing, permanent supportive housing, case management, inventory management, fund management, and reporting across a multi-CoC environment with support for tribal nations, rural and balance-of-state operations, and low-bandwidth/offline functionality.
Round 2 evaluation consists of Pass/Fail requirements for the State of Oregon IT Security Standards spreadsheet and individual key persons' resumes, followed by scored components: interviews (35 points) and demonstrations (65 points), for a total of 100 points. Interviews assess proposer understanding of HMIS operations, client relationships, and organizational competence using a 0-100 scoring rubric. Demonstrations are evaluated across 14 sections (General System Capabilities, Create Participant Profile, Street Outreach Encounter, Day Center Services, Temporary Shelter, Coordinated Entry, Service Referrals, Service Planning/Case Notes, Inventory Management, Fund Management, Reporting, System Administration, Usability, and Functional Fit), with weighted percentages ranging from 4% to 10% per section, using a 1-5 point rubric. Round 1 scores do not carry forward to Round 2; award is based exclusively on Round 2 scoring. The amendment specifies virtual demonstration format with detailed agenda components including 10-minute setup, 20-minute oral presentation, 30-minute interview, 120-minute live system demonstration, and 60-minute Q&A period. No pricing information, set-asides, incumbents, or funding amounts are specified in this amendment document.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| 9053_HMIS Solution RFP_FAQ_final version.docx | DOCX document | |
| 9053_A3_HMIS Solution RFP.pdf | ||
| 9053_RFP_HMIS Solution Software.pdf | ||
| 9053_AttB_Technical Proposal Response Template.docx | DOCX document | |
| 9053_AttF_State of Oregon IT Security Standards.xlsx | XLSX spreadsheet | |
| 9053_AttA_Admin Proposal.docx | DOCX document | |
| HMIS Solution RFP Pre-Proposal Conference-20260921_083313-Meeting Recording.mp4 | MP4 file | |
| 9053_AttD_Price Proposal.xlsx | XLSX spreadsheet | |
| 9053_AttC_Requirements Traceability Matrix.xlsx | XLSX spreadsheet | |
| 9053_AttE_Sample Contract.docx | DOCX document | |
| 9053_A2_HMIS Solution RFP~1.pdf | ||
| Pre-Proposal Conference Attendees.xlsx | XLSX spreadsheet | |
| 9053_A4_HMIS Solution RFP.pdf |
Show all 13
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
Level 3 - Restricted
RFP #S-91400-00016584
HOMELESS MANAGEMENT INFORMATION SYSTEM (HMIS) SOLUTION
PROJECT
BID AMENDMENT #1
SECTION 1: PURPOSE
The purpose of this Bid Amendment is:
1.1) Modify Section 1.2, Schedule, to include Round 2 submission dates and revise Interview/Demos approximate dates.
1.2) Modify Section 5.1, Process Overview, to clarify Round 2 requirements and mandatory documents.
1.3) Add the following sections to provide details on Round 2 evaluation process and scoring methodology:
• Section 5.1, Round 2 Process Overview, Subsections 5.1.1-5.1.7;
• Section 5.2, Round 2 Interview and Demo Scripts;
• Section 5.3, Round 2 Evaluation Process; and,
• Section 5.4, Round 2 Point and Score Calculations.
1.4) Modify Section 6.1, Award Notification Process, to define Award Consideration with Round 2 requirements.
SECTION 2: MODIFICATIONS OF SECTION 5
2.1 MODIFICATION OF SECTION 1.2
Section 1.2 (Schedule), including its respective subsections, are modified as follows (new language is indicated by bold and underlined font, deleted language is indicated by strikethrough font):
1.2 SCHEDULE
The table below represents a tentative schedule of events for this RFP. All times are listed in Pacific Time. All dates listed are subject to change at Agency's discretion. Any changes to the Schedule will be issued via an OregonBuys Amendment. Prospective Proposers are solely responsible for monitoring OregonBuys for any Schedule changes.
Event Date Time
Voluntary Pre-Proposal Conference September 21, 2026 8:30-10:00 AM
Questions / Requests for Clarification Due October 15, 2026 4:00 PM
Answers to Questions / Requests for Clarification Issued (approx.)
October 19, 2026 4:00 PM
Bid Opening (Proposal Due) October 29, 2026 4:00 PM
RFP Protest Period Ends November 5, 2026 4:00 PM
Competitive Range Announcement (approx.)
December 2, 2026 4:00 PM
Competitive Range Protest Period Ends (approx.)
December 7, 2027 4:00 PM
Round 2 Requirements Due December 8, 2027 4:00 PM
Round 2 – Demonstrations (approx.) December 7 14, 2026
– December 10 18, TBD
Issuance of Notice of Intent to Award (approx.)
December 22 28, 4:00 PM
Award Protest Period Ends 7 days after Notice of Intent to Award
2.2 MODIFICATION OF SECTION 5.1
Section 5.1 (Process Overview), including its respective subsections, are modified as follows (new language is indicated by bold and underlined font, deleted language is indicated by strikethrough font):
5.1 PROCESS OVERVIEW
In accordance with RFP Section 4.12, Shortlisted Proposers will advance to this Round 2 of competition. Proposers will provide the following items during Round 2:
• State of Oregon IT Security Standards spreadsheet (Attachment F);
• Individual Key Persons resumes and references;
• Oral presentation;
• Interviews; and
• Oral presentation and Demonstration of the proposed Solution.
Note that Agency anticipates issuing an RFP Bid Amendment with the Notice of Competitive Range to provide the oral presentation agenda, demo scripts, and scoring methodology. Shortlisted Proposers will adhere to the demonstration format specified in the subsequent Bid Amendment.
2.3 ADDITION OF SECTION 5.1 SUBSECTIONS
Section 5.1 (Process Overview) is modified to include subsections as follows:
5.1.1 State of Oregon IT Security Standards Spreadsheet
Proposer shall complete and submit Attachment F, State of Oregon IT Security Standards. The State of Oregon IT Security Standards will be reviewed by the SPC on a Pass/Fail basis. Failure to submit any required item, or submission of an item that is incomplete or non-compliant with stated requirements, may result in the Proposal being deemed non-Responsive.
Proposer shall fill out the Solution Description tab describing the proposed Solution in the description column.
Proposer shall fill out the Phase 1 Bid Response columns in the Standards tab for each row that applies to the proposed Solution indicating: (a) who the requirement is managed by, (b) how the control is implemented, and (c) provide a description of how the control is met.
Proposers may hide or leave blank all rows that do not apply to the proposed Solution.
5.1.2 Individual Key Persons Resumes
Proposer shall submit a resume for each Key Person identified in the Technical Proposal during Round 1. Resumes should include all applicable soft skills, and the following questions should be answered:
• What similar projects have you personally supported, and what was your specific contribution?
• What do you consider your strongest areas of expertise?
Resumes will be reviewed by the SPC on a Pass/Fail basis and will be reviewed by the Evaluation Committee members prior to the Interviews and Demonstrations to prepare additional or clarifying questions of the Key Person(s) experience, qualifications, and soft skills.
5.1.3 Format and Proposer Responsibility
Interviews and Demonstrations will be hosted by Agency in a virtual setting. Upon receipt of notice that Proposer is advancing to Round 2, Agency shall provide the virtual meeting details to the Proposer. Proposer is encouraged to provide Agency with all relevant notices and any associated pre-requisites to aid (or otherwise facilitate) a high-quality connection for Proposer representatives (e.g. preferred browsers, recommended internet connection speeds, turning off un-needed applications). Agency will make reasonable efforts to adhere with such Proposer recommendations.
Agency will record the interviews and demonstrations while adhering to confidentiality restrictions. Agency will use these recordings to assist Evaluators in recalling information presented during demos, as well as noting pertinent guarantees and warranties made by Proposer to discuss during Contract negotiations.
Once the demonstration setup is complete and the demo starts, no additional participants will be allowed to join from either Agency or Proposer.
5.1.4 Interview and Demo Agenda
Proposers shall adhere to the agenda below, and for the leading the Demonstration.
ACTIVITY DURATION*
Agency Introduction and Instructions 10 minutes
Interview and Demonstration Setup** 10 minutes
Oral Presentations 20 minutes
Interview 30 minutes
Break 15 minutes
Demonstrate Sections 1-12 120 minutes
Break 15 minutes
Questions and Answers 60 minutes
*Proposer is accountable for managing its time and the demo process. Proposer and Agency shall keep time for activities.
**This time is allotted to ensure all Agency and Proposer representatives are present and accounted for, audio checks, screensharing checks, etc.
5.1.5 Oral Presentation
Prior to the Interviews and Demonstrations, Proposer shall begin with a brief oral presentation. The oral presentation is intended to allow Proposer to provide an overview of the organization, team, and proposed Solution, and “set the tone” for Interviews and Demonstrations. Oral presentations are not evaluated or scored. The presentation should cover at least the following:
• Introductions
• Solution/Product Overview
• Project Approach
• Maintenance and Operations
5.1.6 Interview and Demonstrations
Proposers shall provide answers to interview questions and a demo of the Solution using the instructions provided in RFP Section 5.2 below.
5.1.7 Questions and Answers
There is a specified duration set aside at the end to answer questions. Evaluators are permitted to request clarification on functionality at any time during the demos. Proposer is responsible for managing their time; therefore, Proposer may elect to answer the question during the scripted scenario (e.g., for quick and simple accommodation) or advise the Evaluator to ask the question again during the time allotted for Questions and Answers.
2.4 ADDITION OF SECTION 5.2
Section 5.2 (Round 2 Interview and Demo Scripts), including its respective subsections, are added as follows:
5.2 ROUND 2 INTERVIEW AND DEMO SCRIPTS
5.2.1 Interview Scripts
This interview is designed to provide the Evaluators with insight into the Proposer’s organization and skills in working relationships with clients. All questions must be answered with a detailed explanation. The Interview shall be no longer than 30 minutes.
Proposer shall answer the following questions:
• Can you walk us through how you explain complex information clearly to End Users?
• What does the organization need from a client to work effectively?
• How many clients have transitioned away from the proposed Solution in the last 5 years?
5.2.2 Demo Scripts
This demonstration is designed to provide Evaluators with a comprehensive understanding of the proposed Solution’s capabilities and constraints. The features below cover the minimum features that Agency expects to see during the demonstration.
Proposer may demonstrate additional features for each scenario, as time permits.
All demonstrations must be performed live in a configured demonstration environment.
The environment must reflect an Oregon Multi-CoC configuration with at least two CoC partitions (representing any two of OR-502, OR-503, OR-504, or OR-505), multiple provider organizations, and representative participant records across program types (Street Outreach, Emergency Shelter, Rapid Re-Housing, Permanent Supportive Housing, coordinated entry).
Demonstrations must follow the sections in the order presented below. Demonstrating the proposed Solution in a different order might result in a lower score for the overall demonstration.
Section 1: General System Capabilities
Demonstrate core System functionality that spans all OMC User types and workflows.
Evaluators will assess intuitive navigation, role-based access enforcement, cross-CoC data sharing controls, and System responsiveness.
1. Show how a User searches for participant profiles based on different criteria in the
HMIS, such as name, date of birth, PII, SSN or IDN, description, etc.
2. Show how the HMIS returns potential matches to a fuzzy search.
3. Show how a User enters or configures System-wide alerts in the HMIS.
4. Show how a User views publicly available information in the HMIS.
5. Show how a User views client-specific information in the HMIS.
6. Show how the HMIS displays a participant’s prioritization status for housing, shelter, or other services.
7. Show how a User documents participant encounters in the HMIS, including individual profile updates and bulk/mass updates.
8. Show how a User schedules future actions in the HMIS.
9. Show how the HMIS prompts a User to complete scheduled actions.
10. Show how the HMIS logs services from the perspective of both the participant receiving services and the provider providing services.
11. Show how a User views and sorts/filters a participant's past program enrollments or service history in the HMIS.
12. Show how a User defines groups of participants in the HMIS (e.g. households, class or event attendance).
13. Show how a User assigns participants to groups (e.g. households) and views participant groups in the HMIS.
14. Show how a User creates and modifies custom assessments in the HMIS, such as coordinated entry assessments.
15. Show how a User modifies completed assessments.
16. Show how a User views previous/historical answers to assessment questions.
17. Show how the HMIS limits a User’s data access and functionality based on their assigned role and permissions.
18. Show how the HMIS enables a User to have multiple assigned roles and/or permissions.
19. Show how the HMIS enables Users to view and share information across CoC partitions within the HMIS.
20. Show how a User defines and modifies information sharing and visibility rules across CoC partitions within the HMIS.
21. Show how the HMIS enables messaging between Users.
22. Show how a User records participant incidents in the HMIS.
23. Show the different methods a User can use to import data into the HMIS.
24. Show the different methods a User can use to export data from the HMIS.
25. Show how the HMIS supports dashboarding within the System.
Section 2: Create Participant Profile
Demonstrate the new participant intake process, including Universal Data Element (UDE) collection per FY2026 HMIS Data Standards, duplicate prevention, household management, and consent management — all within the Oregon Multi-CoC context.
1. Show how a User begins the process of creating a new participant profile in the
HMIS
2. Show how the HMIS prompts a User to collect basic participant information (e.g., name, date of birth, email address, and phone number).
3. Show how the HMIS prevents duplicate client record creation.
4. Show how a team member enters basic participant information in the HMIS.
5. Show how a User indicates if a participant profile should be part of a household unit with other participant profiles.
6. Show how a User adds a given participant to multiple households/families in the
HMIS.
7. Show how a User indicates if a given participant is head of household/family.
8. Show how the HMIS prompts a User to collect detailed participant information in the HMIS (e.g., proof of income, proof of disability, accessibility needs, housing history).
9. Show how a participant can sign and retract agreements at any time in the HMIS, including client consent forms and data sharing agreements.
Section 3: Street Outreach Encounter
Demonstrate how the System supports OMC street outreach workers in the field, including mobile functionality, real-time data capture, and geospatial tools. OMC street outreach programs span urban and rural areas across Oregon. Demonstrate how the System supports low-bandwidth and offline scenarios common in rural Oregon.
1. Show how a User uses the HMIS on a mobile device including describing any limitations in functionality.
2. Show how a User logs an outreach attempt in the HMIS.
3. Show how a User logs an outreach encounter in the HMIS.
4. Show how a User adds or modifies outreach encounter information in the HMIS.
5. Show how the HMIS allows Users to opt to log real-time information associated with an outreach encounter (e.g., location, date, time, current HMIS User, etc.).
6. Show how a User tags locations where individuals or groups are located via the
HMIS.
7. Show the HMIS’ geo-spatial tools and how they are compatible with geo-spatial data.
8. Show how a User records outreach attempt information on an individual participant’s record or grouped with other encounters on an outreach log.
9. Show how a User indicates if future outreach is necessary, including scheduling future outreach attempts.
10. Show how the HMIS prompts a User to follow up with a participant for scheduled outreach attempts.
11. Show how a User views a consolidated log of outreach attempts and encounters for a given participant in the HMIS.
12. Show how the HMIS prompts a User to view the most recent outreach encounter information for a participant during a new outreach encounter.
Section 4: Day Center Services and Attendance
Demonstrate how the system captures OMC day center service delivery, including both known participant records and walk-in encounters for unidentified individuals.
1. Show how a User records a day center visit in the HMIS.
2. Show how the HMIS maintains a record of all participants served, and services rendered during a given day center worker’s shift in a day center shift log.
3. Show how a User receives notifications of incoming day center arrivals in the HMIS.
Section 5: Determine and Assign Temporary Shelter
Demonstrate end-to-end temporary shelter management, including inventory management, referral workflows, waitlists, and check-in/check-out processes. OMC shelters serve diverse populations across rural and urban settings — demonstrate how the System supports population-specific shelter inventory and multi-provider coordination across the Oregon Multi-CoC.
1. Show how a User updates shelter resource information in the HMIS (e.g., capacity, schedule).
2. Show how a User defines requirements or characteristics for individual shelter beds/units (e.g., pet restrictions, systems of care served).
3. Show how the HMIS displays current shelter availability and associated attributes (e.g., locations, populations served, beds/units available, ADA-accessible spaces).
4. Show how the HMIS prompts a User to complete an initial shelter screening with a participant.
5. Show how a User records a participant’s shelter needs and initial screening information.
6. Show how a User assigns specific beds/units at a shelter to a specific participant.
7. Show how a User documents a participant’s stay at a shelter in the HMIS.
8. Show how the HMIS updates shelter inventory as a participant is checked-in or checked-out of a facility.
9. Show how a User adds a participant to a shelter waitlist.
10. Show how the HMIS displays waitlist information for a participant on a waitlist, including priority on waitlist and estimated time to placement.
11. Show how the HMIS maintains a centralized shelter waitlist, including lists of available shelter resources and prioritized participants in need of shelter.
12. Show how a User refers a participant to a shelter in the HMIS.
13. Show how a User receives and views a shelter referral in the HMIS.
14. Show how a User declines a shelter referral in the HMIS, including the reason for declining.
15. Show how a User accepts a shelter referral in the HMIS.
16. Show how the HMIS enrolls a participant in a shelter program in the HMIS.
17. Show how the HMIS notifies a User when a shelter referral is declined or accepted.
18. Show how a User records shelter walk-ins in the HMIS, including accepted and denied walk-ins and the reason for denial.
19. Show how a User updates the HMIS when a participant is no longer using a shelter bed.
20. Show how a User records participant exclusion notes in the HMIS.
21. Show how a User views participant exclusion notes in the HMIS.
Section 6: Coordinated Entry Intake and Housing Prioritization
Demonstrate the full coordinated entry workflow from initial intake through prioritization, including support for FY2026 coordinated entry data elements (4.12, 4.19, 4.20, 4.21). The Oregon Multi-CoC operates under different coordinated entry policies across OR-502, OR- 503, OR-504, and OR-505 — demonstrate how the System supports jurisdiction-specific coordinated entry configuration within a single OMC instance.
1. Show how a User initiates coordinated entry intake assessment in the HMIS.
2. Show how a User conducts system of care screening to determine applicable system(s) of care.
3. Show how the HMIS determines and/or displays the applicable system(s) of care for the participant.
4. Show how a User can confirm which eligible system(s) the participant would like to be considered part of, for participants that are eligible for multiple systems of care.
5. Show how the HMIS displays applicable coordinated entry assessment(s) based on preferred eligible system(s) of care.
6. Show how the User enters coordinated entry assessment responses from the participant in the HMIS.
7. Show how the HMIS applies skip logic based on preconfigured business rules when displaying coordinated entry assessment questions.
8. Show how the HMIS calculates priority score(s) and/or priority status for the participant based on assessment information, preconfigured prioritization rules, and CoC policies.
9. Show how the HMIS displays prioritization score(s) and/or status after the assessment is completed.
10. Show how the HMIS displays prioritization score(s) and/or status on a participant’s profile.
11. Show how the HMIS monitors participant priority status for participants that are not initially deemed priority status.
12. Show how the HMIS prompts Users to conduct coordinated entry re-assessments for participants that have not become priority status after a designated time.
13. Show how Users can create a contact record for participants initiating coordinated entry through a phone team.
14. Show how coordinated entry assessment questions can be configured differently for different CoCs and different participant populations.
15. Show how coordinated entry assessment questions and skip logic can be modified by system administrators.
16. Show how housing prioritization rules can be configured differently for different CoCs and different participant populations.
17. Show how housing prioritization rules can be modified by system administrators.
Section 7: Refer an Individual to Eligible Services
Demonstrate the end-to-end service referral workflow, including eligibility-based service matching, waitlist management, referral tracking, and cross-CoC referral capability within the Oregon Multi-CoC.
1. Show how a User enters a participant’s service needs in the HMIS.
2. Show how a User searches for available services in the HMIS.
3. Show how the HMIS displays the currently available services.
4. Show how a User adds a participant to a service waitlist.
5. Show how the HMIS displays waitlist information, including priority on waitlist and estimated time to placement.
6. Show how a User refers a participant to a service provider in the HMIS.
7. Show how the HMIS notifies a User of a service referral.
8. Show how a User reviews a service referral in the HMIS.
9. Show how a User accepts or declines a service referral in the HMIS.
10. Show how the HMIS notifies a User when a service referral is declined or accepted.
11. Show how a User declines or accepts a walk-in service request in the HMIS.
12. Show how a User records services that are provided in the HMIS.
13. Show how service inventory is kept updated in the HMIS.
14. Show how the HMIS enables Users to refer participants to services across CoC partitions within the HMIS.
Section 8: Record and Update Service Plan, Care History, and Case Notes
Demonstrate the full case management workflow from referral through case closure, including caseload management, service planning, appointment scheduling, and case notes.
The Oregon Multi-CoC includes rural providers who rely heavily on case management functionality for isolated clients.
1. Show how a User refers a participant to case management in the HMIS.
2. Show how the HMIS notifies a User of a case management referral.
3. Show how a User reviews a case management referral and assigns a participant to a case management program.
4. Show how a User adds a participant to a case management waitlist.
5. Show how the HMIS notifies a participant when they are added to a case management waitlist and updates them of their waitlist status on a regular cadence until they are added to an active caseload.
6. Show how a User adds a participant to an active caseload.
7. Show how the HMIS notifies a User when a participant is added to their active caseload.
8. Show how a User creates a new Service Plan for a participant
9. Show how a User reviews a participant’s profile and existing Service Plan in the
HMIS
10. Show how a User updates a participant’s service plan in the HMIS.
11. Show how a User records participant assessments in the HMIS, including selecting the proper assessment to conduct and recording participant responses.
12. Show how a User uploads participant documentation to the HMIS.
13. Show how a User enters notes on a participant's profile in the HMIS, including general client notes and restricted case notes.
14. Show how a User searches notes on a participant’s profile.
15. Show how a User schedules an appointment with a participant in the HMIS.
16. Show how the HMIS notifies a participant when an appointment is scheduled and reminds them of the appointment prior to the appointment date.
17. Show how a User schedules future case management activities in the HMIS.
18. Show how the HMIS prompts a User to conduct case management activities based on the defined schedule and service plan.
19. Show how the HMIS prompts a User to close out a participant’s case.
20. Show how the HMIS displays updates to a User’s assigned caseload as participants are assigned to or removed from their caseload.
Section 9: Manage Inventory
Demonstrate service and resource inventory management across provider organizations and CoC partitions. The Oregon Multi-CoC includes Tribal Nation programs — demonstrate how the System supports tribal provider organizations as distinct entities with appropriate access controls.
1. Show how a User adds resource inventory to a service provider in the HMIS.
2. Show how a User defines the resource’s attributes in the HMIS.
3. Show how the HMIS displays resource inventory.
4. Show how a User views program and resource utilization by location, participant, and provider in the HMIS.
5. Show how a User updates resource inventory in the HMIS.
6. Show how a User removes resource inventory from the HMIS.
7. Show how the HMIS hides removed resources from the inventory but does not delete the information from the System.
Section 10: Manage Funds
Demonstrate fund management capabilities, including fund definition, usage tracking, and request/approval workflows. OMC providers manage funds from multiple federal sources, as well as Oregon state and local sources.
1. Show how a User defines fund details and fund usage rules (e.g., amount of money, eligible services, other eligibility notes) in the HMIS.
2. Show how a User views fund usage information (e.g., how much was spent on which dates, how much remains) in the HMIS.
3. Show how a User submits a request for available funds in the HMIS.
4. Show how a User reviews and rejects/approves requests for available funds in the
HMIS.
Section 11: Reporting
Demonstrate System’s out-of-the-box reports, standardized reports from HUD, and ad hoc/custom reporting options.
1. Show out-of-the-box reports available.
2. Show standard HUD reports available.
3. Show how a User would run an out-of-the-box report, including navigation and available filters or parameters.
4. Show built-in visualization, built-in guidance or interpretative text, and any features that support accuracy such as data validation.
5. Show how a non-technical End User can build a custom report from scratch, including field, filter, grouping, and calculation selections.
6. Show report performance for a large or complex dataset.
7. Show report performance for advanced reporting features such as cross-tabbing, multiple layered filtering, merging datasets, and other deeper analysis functions.
8. Show how reports can be exported, scheduled, automated, or shared with other
HMIS Users.
9. Show how reports and data can be authorized for different permission sets.
10. Show collaboration features between reports.
11. Show custom visualization element creation.
Section 12: System Administration
1. Show the HMIS audit functionality of User actions.
2. Show how audit logs can be filtered, sorted, or exported.
3. Show how the HMIS traces changes to client records or program enrollments.
4. Show how the HMIS sets retention periods and manages security and compliance.
5. Show how HMIS system administrators can manage role and permission changes, monitor administration audit logs, and run audit-specific utilities.
6. Show how the HMIS tracks failed logins, unusual activity, and security events.
7. Show audit-specific reports or dashboards.
8. Show HMIS tools for system administrators to troubleshoot incidents reported.
Section 13: Usability (Not Demonstrated but Scored)
Proposers will be evaluated and scored for the overall usability of the System. This is not a demonstrated Section, but an overall evaluation of previous Sections 1-12. The following criteria will be evaluated:
1. How easily navigated is the System, including accessibility features (508/WCAG 2.1
AA compliance, ADA accommodations, multi-language support)? Does the system make it easy for Users with varying levels of technical ability to find what they need?
2. Will the System enable effective delivery of services to clients? Does the System support the workflows that frontline workers use every day, without creating barriers to service delivery?
3. Will the System make the work and daily tasks of Users easier? Does the System eliminate redundant data entry, reduce time spent on administrative tasks, and support staff in focusing on client interaction rather than ‘feeding the software’?
4. Based on the demonstration, would the Solution likely be successfully adopted and frequently used? Would frontline workers, Agency administrators, and staff embrace the Solution as a daily tool?
5. Is the System intuitive and easy to learn? Does the System appear learnable by Users with varying levels of technical expertise, including rural and tribal agency staff who may have limited IT support?
Section 14: Functional Fit (Not Demonstrated but Scored)
Proposers will be evaluated and scored for the overall usability of the System. This is not a demonstrated Section, but an overall evaluation of previous Sections 1-12. The following criteria will be evaluated:
1. Does the Solution comprehensively address the functional requirements of Agency, the Oregon Multi-Continuum of Care, and the diverse program types operated across OR-502, OR-503, OR-504, and OR-505, including street outreach, day center, temporary shelter, coordinated entry, housing match and placement, service referrals, and case management? Does the Solution demonstrate features and functions that meet the requirements set forth in Attachment C – Requirements Traceability Matrix.
2. Does the Solution provide workflows that are efficient and logical, following natural task sequences that align with how Agency and Oregon Multi-CoC HMIS Users perform work? Do the Solution workflows minimize unnecessary steps, redundant data entry, and procedural detours that would impede service delivery or staff productivity?
3. Does the Solution support Oregon Multi-CoC operational workflows, including: (a) Multi-CoC data sharing and visibility controls across OR-502, OR-503, OR-504, and OR-505; (b) Tribal Nation and tribally designated housing entity participation; (c) rural and Balance of State service delivery, including low-bandwidth and offline functionality; and (d) Oregon-specific coordinated entry configurations that vary across CoC partitions?
4. Does the Solution position Agency and the participating Continuums of Care to advance toward shared strategic goals, including: (a) improved data quality across the Oregon Multi-CoC; (b) increased service coordination across providers and partitions; (c) measurable progress toward reducing homelessness; and (d) sustained compliance with HUD performance benchmarks, including System Performance Measures and FY 2026 HMIS Data Standards reporting requirements?
5. Does the Solution demonstrate Proposer's capability of successfully migrating Agency from current System within the required timeline while maintaining data integrity and minimizing disruption?
2.5 ADDITION OF SECTION 5.3
Section 5.3 (Round 2 Evaluation Process), including its respective subsections, are added as follows:
5.3 ROUND 2 EVALUATION PROCESS
5.3.1 State of Oregon IT Security Standards Review and Responsiveness Determination
The State of Oregon IT Security Standards (Attachment F) will be reviewed by the SPC on a Pass/Fail basis. Failure to submit any required item, or submission of an item that is incomplete or non-compliant with stated requirements, may result in a Proposer being deemed non-Responsive. If a Shortlisted Proposer is deemed non-Responsive, Agency maintains the ability to disqualify Proposer and move forward with the next highest-ranking Proposer of Round 1.
5.3.2 Individual Key Persons Resumes Review and Responsiveness Determination
Proposers shall submit all Key Persons identified in Round 1 resumes and answers to questions listed in Section 5.1.2. Resumes and answers will be reviewed by the SPC on a Pass/Fail basis. Failure to submit any required item, or submission of an item that is incomplete or non-compliant with stated requirements, may result in a Proposer being deemed non-Responsive. If a Shortlisted Proposer is deemed non-Responsive, Agency maintains the ability to disqualify Proposer and move forward with the next highest-ranking Proposer of Round 1.
5.3.3 Interview Evaluation Framework and Criteria
Proposers will be evaluated on their response to interview questions based on the following criteria:
• Proposer has directly and completely answered the question.
• Proposer has shown mastery of HMIS concepts, client relationships, and communication practices.
• Proposer uses real examples, metrics, or outcomes when possible.
• Proposer demonstrates clear reasoning and insight—not just statements of capability.
• Proposer demonstrates organization’s competence, stability, and communication strength.
Evaluators will assign one score for the overall impression of the Proposer’s answers to the interview questions listed in Section 5.2.1. Evaluators will assign scores using the scoring rubric below:
SCORING RUBRIC
SCORE EXPLANATION
0 – 20 POOR – An unacceptable response that does not meet the requirements set forth in the RFP. Response may be irrelevant, missing, incorrect, or show a lack of understanding of HMIS operations, client needs, or communication practices.
21 – 40 FAIR – Response meets only a portion of what the question is asking.
Proposer shows limited understanding, relies on vague generalities, or makes statements that do not clearly explain how organization works.
41-69 ADEQUATE – Response is acceptable but basic. Proposer meets the minimum expectations and demonstrates the ability to comply with RFP expectations but adds little insight or depth. Responses may feel generic, high‑level, or incomplete.
70 – 89 VERY GOOD – Response is solid, informative, and demonstrates above‑average knowledge. Proposer provides helpful detail, but may miss an opportunity to go deeper, provide examples, or show distinctive strengths.
90-100 OUTSTANDING - Proposer has demonstrated in a clear and concise manner deep expertise, confidence, and readiness. Responses are concise yet thorough, easy to follow, and show strong command of the subject. Proposer goes beyond surface‑level statements by offering examples, describing processes, and showing meaningful awareness of client needs.
5.3.3 Demonstration Evaluation Framework and Criteria
The Demonstration evaluates how well the Proposer’s Solution performs required HMIS functions and how usable and functional the Solution is for Oregon Multi‑CoC users.
Demonstration scoring is divided into fourteen (14) sections:
• Demo Sections 1-12 cover functional demo areas directly tied to HMIS workflows and System capabilities.
• Sections 13-14 evaluate overall usability and overall functionality.
Each section receives a raw score between 1 and 5, based on how effectively the Proposer demonstrates the required features and behaviors. The Evaluation Committee will score this criterion using the rubric below:
SCORING RUBRIC
SCORE EXPLANATION
1 UNSATISFACTORY – Proposer demonstrates very little of the required functionality. Workflows are incomplete, incorrect, or misaligned with expectations for Oregon Multi‑CoC usage. Evaluators gain little confidence in the Solution’s capability.
2 POOR – Proposer shows only partial functionality. Several required steps or behaviors are missing, unclear, or poorly demonstrated.
Evaluators have concerns about the Solution’s ability to perform reliably or meet user needs.
3 FAIR – Proposer demonstrates required functionality at a basic, satisfactory level. Some workflows may be incomplete, generic, or lacking depth. Evaluators see that requirements are generally met but may identify notable gaps or uncertainties.
4 GOOD – Proposer demonstrates most required functionality with only minor gaps, inefficiencies, or unclear steps. System behavior is strong and mostly consistent. Evaluators remain confident in the Solution, though small improvements or clarifications may be needed.
5 OUTSTANDING – Proposer clearly and completely demonstrates all required functionality for the section. Navigation, workflow logic, accuracy, and responsiveness meet or exceed expectations for an Oregon Multi‑CoC environment. Demonstration is well‑organized, intuitive, and leaves Evaluators highly confident in the Solution’s capability.
Each section is assigned its own total points, reflecting its contribution toward the total Demonstration Score. The points for Section 1-14 are as follows:
SECTION PERCENTAGE
Section 1: General System Capabilities 5%
Section 2: Create Participant Profile 5%
Section 3: Street Outreach Encounter 5%
Section 4: Day Center Service and Attendance 5%
Section 5: Determine and Assign Temporary Shelter 8%
Section 6: Coordinated Entry Intake and Housing Prioritization 8%
Section 7: Refer an Individual to Eligible Services 4%
Section 8: Record and Update Service Plan, Care History, and Case Notes
10%
Section 9: Manage Inventory 5%
Section 10: Manage Funds 5%
Section 11: Reporting 10%
Section 12: System Administration 10%
Section 13: Usability 10%
Section 14: Functional Fit 10%
Evaluators will assign scores for each criterion listed 1 through 5. Each section’s raw score will be converted into weighted points according to its percentage of the total demonstration score. Once scoring is complete, the adjusted weights will be totaled for the Proposer’s total Demonstration Score.
(Example: Proposer A scores a 4 in Section 5. 4 divided by 5 equals 0.8. 0.8 multiplied by 8 equals 6.4. A total of 6.4 points for Section 5 would then be added to the other sections awarded points for a total Demonstration Score.)
2.6 ADDITION OF SECTION 5.4
Section 5.4 (Round 2 Point and Score Calculations), including its respective subsections, are added as follows:
5.4 ROUND 2 POINT AND SCORE CALCULATIONS
The answers to Interview questions are scored by an evaluation committee. The evaluators will score the answers based on their overall impression for a value of 0 through 100 points. The points are then divided by the total max points possible and multiplied by the total points available, as shown in the table below, for the total points awarded.
(Example: Proposer A receives a score of 70 out of 100 points. The SPC takes the total points awarded and divides the maximum points possible, which is then multiplied by 35 points of the overall total points score. 70 divided by the max points possible of 100 is 0.7.
0.7 multiplied by 35 is 24.5. Proposer A receives 24.5 points for that criterion.)
The Demonstration is scored by an evaluation committee. Each of the fourteen (14) Demonstration sections receives a raw score between 1 and 5. The raw score for each section is divided by 5 (the highest possible score provided by an evaluator). That number is then multiplied by the weighted percentage for the corresponding section, producing the section’s weighted points. All weighted section points are then added together to obtain the Proposer’s total Demonstration Score. The points are then divided by the total max points possible and multiplied by the total points available, as shown in the table below, for the total points awarded.
(Example: Proposer A receives a total Demonstration score of 85 out of 100 points. The SPC takes the total points awarded and divides the maximum points possible, which is then multiplied by 65 points of the overall total points score. 85 divided by the max points possible of 100 is 0.85. 0.85 multiplied by 65 is 55.25. Proposer A receives 55.25 points for that criterion.)
Round 2 Final Score
Proposal Section Points Available
State of Oregon IT Security Standards 0 (Pass/Fail)
Individual Key Persons Resumes 0 (Pass/Fail)
Interviews 35
Demonstrations 65
Total Points 100
The SPC will take each Evaluation Committee member’s individual scores for each Proposer and average the score for each Proposer across committee scores.
2.7 MODIFICATION OF SECTION 6.1
Section 6.1 (Award Notification Process), including its respective subsections, are modified as follows (new language is indicated by bold and underlined font, deleted language is indicated by strikethrough font):
6.1 AWARD NOTIFICATION PROCESS
6.1.1 Award Consideration
Agency, if it awards a Contract, shall award a Contract to the highest-ranking Responsible Proposer based upon the scoring methodology and process described in Section 3 and Section 4 of this RFP. Agency may award less than the full Scope defined in this RFP.
Agency shall conduct this procurement using a multistep process under ORS 279B.060 and OAR 137‑047‑0261. Round 1 is used solely to determine Shortlisted Proposers in accordance with Section 4.12, and Agency shall not carry Round 1 scores forward into Round 2.
Only Shortlisted Proposers advance to Round 2. Round 2 scores are the exclusive basis for Contract award. Agency, if it awards a Contract, shall award a Contract to the highest‑ranking Responsible Proposer based exclusively upon the scoring methodology and evaluation process described in Section 5 of this RFP, which governs all scoring elements (including Interviews and Demonstrations) used to determine final competitive standing and award.
Section 5 shall be the basis of the award. Round 1 determines Shortlisted Proposers (per Section 4.12), and Round 2 determines award.
Agency reserves the rights provided under ORS 279B.100 and OAR 137‑047‑0670, including the right to reject any or all Proposals, cancel the procurement, waive minor informalities, and to award less than the full Scope defined in this RFP.
File details come from the government source that posted it. Updated .