OHA-OHP HCI RFP QandA ALL vPOST.pdf

S-DASOBO-00016280 OHA-OHP HCI Porta l RFP Q&A

# Subject Area Question Subject Answer

1 Pre-Proposal Conference

What time is the Pre-Proposal Conference on September 3, 2026?

The Pre-proposal conference is at 9:00 am on September 3, 2026. Refer to the conference call-in information in RFP Section 3.2.

2 EDI X12 / MMIS trading partner certification timeline (Attachment B-2, Claims category, CLM6)

The Requirements Matrix identifies EDI X12 claims submission to MMIS as a Mandatory (High priority) requirement.

Please describe the process and typical timeline for a new vendor to become an approved EDI X12 trading partner with Oregon's MMIS - specifically, whether trading-partner testing and certification must be completed prior to Proposal submission, or whether this may be completed post-award during implementation.

Becoming an approved trading partner involves:

• Submitting a TPA with original signatures

• Waiting ~30 to 45 days for processing

• Completing Technical testing afterward which can take several weeks Trading partner approval will be required before the portal goes live, but not before Proposal submission.

Vendors responding to the RFP must commit to completing trading partner approval process during implementation, not upfront.

3 EPIC/EHR integration scope (Attachment B- 2, Integration category, INT1)

Please clarify whether "EPIC/EHR integration" requires the Proposer to hold Epic App Orchard certification or an existing Epic partnership at the time of Proposal submission, or whether this integration may be developed post-award as part of implementation.

Additionally, is integration required specifically with Epic, or with any EHR platform in use by OHP-enrolled providers more broadly?

Epic certification is not required at the time of submission, and the ability to integrate with Epic and other EHRs is a high-priority requirement but not mandatory. Proposers planning on EHR integration should demonstrate they have the capacity and plan to integrate with Epic and other relevant EHRs used by OHP providers during the implementation period.

Proposals should include whether integration is already established, examples of previous successful integrations, an integration strategy, and anticipated timeline.

4 Teaming/subcontractor disclosure format (Section on Proposal submission requirements / Attachment

For Proposers submitting as a prime/subcontractor team, what is the required format for disclosing the teaming arrangement in the initial Proposal (e.g., a letter of intent, executed teaming agreement, or narrative disclosure within the SOW)?

Please confirm whether this disclosure belongs in Attachment A, the draft SOW, or a separate document.

The RFP does not prescribe a specific format for disclosing prime/subcontractor teaming arrangements. Please refer to section 2.5.2.b, for required details for Staffing plans and subcontracting.

There is no specific attachment or format required.

5 Documentation standard for "Available Soon" responses (Attachment B-2 Requirements Matrix)

For Mandatory requirements marked "Available Soon" (i.e., requiring custom development within approximately one year of contract execution), what level of supporting detail is expected to substantiate feasibility - for example, is a technical approach narrative sufficient, or should Proposers include architecture diagrams, a staffing plan, or a development timeline as part of the Requirements Matrix response or the draft SOW?

The RFP does not prescribe a specific format or level of detail; a technical approach narrative addressing feasibility is sufficient. However, the narrative provided must have adequate details of how the requirement will be achieved and may include architecture diagrams, staffing plans, and a development timeline as part of the response.

6 Security self-attestation documentation (NIST SP 800-53 Moderate)

Since GovRAMP/StateRAMP authorization is not required and a self-attested NIST SP 800-53 Moderate compliance statement is acceptable, please clarify what specific documentation format satisfies this requirement at Proposal submission - a narrative statement as described in the RFP body, or a completed System Security Plan (SSP) or equivalent artifact.

The RFP’s requirement at Proposal stage, include:

• A declaration that your solution meets NIST SP

800-53 Moderate baseline

• A brief technical narrative explaining your approach (i.e., encryption, identity management, incident response)

Attachment D, the Statewide Information Security Standards Spreadsheet is provided only to inform development of the Proposed Solution. Completion or submission is NOT required for the initial Proposal submitted in response to this RFP. However, submission may be required for subsequent evaluations rounds, and completion by the Successful Proposer will be required as a condition for contract execution.

7 Attachment D (Statewide IS Standards Spreadsheet) submission timing conflict

The RFP body states that Attachment D, the Statewide Information Security Standards Spreadsheet, is provided only to inform solution development and that "completion or submission is NOT required for the initial Proposal."

However, Attachment D's own Instructions tab labels a section "PHASE 1 BID RESPONSE" and directs the Proposer to complete the Solution Description tab and the Standards tab (columns D through L, covering all ~181 listed controls) as part of that phase.

Please clarify whether "Phase 1 Bid Response" refers to the initial Proposal due at Bid Opening (October 1, 2026), or to a later stage such as the Competitive Range round, and confirm whether Attachment D completion is required with the initial Proposal submission.

Completion or submission is NOT required for the initial Proposal submitted in response to this RFP.

However, submission may be required for subsequent evaluations rounds, and completion by the Successful Proposer will be required as a condition for contract execution.

8 Data Conversion & Migration

Is there an existing interim system (manual or automated) OHA uses today for HCI scheduling or claims that the new Portal would need to migrate data from?

No there is not an existing system. However, it is anticipated that data from the HCI Central Registry and potentially data from MMIS may be pulled into use with the Portal solution.

9 Attachment D Attachment D is deferred to later rounds, but is a GovRAMP-Authorized (or equivalent) product effectively necessary to survive Round 1, or is a compliance narrative alone sufficient at this stage?

A compliance narrative is sufficient at RFP submission time. (Please refer to questions 6 and 7)

10 Claim Volume Can OHA share any estimate of anticipated encounter or claim volume (even a rough range), since none is stated in the RFP?

(Note: Including answer to #22 about modality here.)

Though we do not know the exact number, here are some data points that may be helpful for projection purposes.

The State of Washington has similar demographics, so the portal dashboard for the Washington Health Care Authority may be viable comparable system.

To supplement that, Oregon Health Authority analysis suggested an estimated 200,000 to 400,000 encounters per year needing the services of an external health care interpreter (i.e.: not provided by in-language provider or in-house health care interpreter), assuming robust adoption by providers and sufficient HCIs available via the portal.

At this time, our models use an assumption / estimation of 80% in-person and 20% virtual appointments for the encounters scheduled via the portal.

For encounters serving the approximately 50% of language needs in Fee-for-Service, Medicaid will pay for the encounter, which is anticipated to encourage providers to prioritize in-person interpretation.

11 Organizational Experience

Can the Prime Proposer's Organizational Profile and Experience & Capabilities response rely primarily on a subcontracted technology/OEM partner's implementation history, or must the Prime itself hold at least one of the three required similar-scope implementations (Section 2.5.2.b?

Yes, it is acceptable to rely on subcontractors to meet the requirement. The Prime should be able to demonstrate their implementation experience with the proposed subcontractor.

12 Technical Integration Specifics

What integration standard/API does OHA's MMIS currently expose for claims and eligibility verification (e.g., X12 837/835, custom API, HL7)?

X12 837/835 is utilized with the Oregon MMIS system.

13 Technical Integration Specifics

What is the current data structure and access method for the HCI Central Registry - is an API available today, or would this require a net-new interface?

HCI Central Registry is a stand-alone system hosted by OHA/OIS. At this time there are no APIs exposed.

14 Security & Compliance What is the expected timeline and process for obtaining the State's advance consent for any offshore resources (Sample Contract Section 27.2), in case a partner's development team includes non-U.S. staff?

The advanced consent process may take several months to complete.

Please review the Information Security, DAS Statewide Policy 107-004-052, found online at https://www.oregon.gov/das/Pages/policies.aspx#IT, pertaining to State systems and security, including its restrictions on offshore and foreign services.

15 PreProposal Conference

Is the successful Contractor expected only to provide and operate the scheduling and claims platform, or must the Contractor also maintain or provide access to a network of interpreters and language service companies to fulfill encounters when no Oregon Credentialed HCI accepts a request?

Yes, the proposer must provide the ability to fulfill appointments when Oregon-credential interpreters are not available. This is referred to as ‘overflow’ in requirement #56.

Additionally, a nonprofit Recruitment and Retention partner will be engaged to help fill last-minute appointment spots with Oregon-credentialed interpreters, and this option should be exercised before relying on the ‘overflow’ option.

https://www.oregon.gov/das/Policies/107-004-052.pdf https://www.oregon.gov/das/Pages/policies.aspx#IT

16 PreProposal Conference

Billing provider. "The Trading Partner Agreement requires an enrolled Medicaid provider with an NPI and Medicaid ID, who designates an EDI submitter. Under ESB 1578's direct payment to HCIs, will interpreters be enrolled as Medicaid providers, typical or atypical? If so, does each HCI execute a TPA naming the Contractor as submitter, and is there a bulk enrolment path, given 30-45 day processing across thousands of interpreters? Or will OHA hold a single trading-partner arrangement for the Portal?"

We are currently working with MMIS to get HCIs set up as providers in the system in support of direct payments.

The details of the claim submittal process will be fleshed out in design sessions with the selected vendor.

17 PreProposal Conference

Grievances. "Section 2.4.10 places grievance intake and resolution in the Contractor's scope. Does resolution mean the Contractor operates intake, case management and routing while OHA program staff render determinations, or is the Contractor expected to render determinations?

The contractor will be expected to provide first-level support for customer grievances to establish where the discrepancy exists, which will then determine which party has final determination responsibility.

18 PreProposal Conference

Who disburses. "Does 'pay HCIs directly' mean the Contractor disburses funds, or that the Portal transmits payment instructions to MMIS and the CCOs, who disburse?"

It is anticipated that MMIS will be issuing the payments directly to the HCI for services provided to qualified participants.

19 PreProposal Conference

CCO claims path. "For CCO-enrolled members, are claims submitted to each CCO directly, or routed through MMIS as encounter data? Does the Contractor interface with all sixteen CCOs individually?"

This has yet to be determined and is expected to be defined in the design and configuration sessions.

20 PreProposal Conference

Customer service scope and budget. "Is the scheduling and claims support function expected to be staffed by the Contractor for the full term, is there a volume or coverage assumption to price against, and does the $1.5M initial-term estimate include it?"

The initial year of customer service is anticipated to be included in the $1.5M initial-term estimate.

Please see encounter estimates from Q#10, with an expected ramp-up rate.

21 PreProposal Conference

For Requirement PSC6, does “a solution for finding an HCI if there isn’t one available in the Registry” require the Contractor to recruit, credential, contract with, dispatch, or pay non-registry interpreters, or only document and facilitate the Provider’s good-faith effort?

Please see answer to #15.

22 PreProposal Conference

Do you have an estimate of encounters that this portal should handle per modality?

Please see answers for Q#10.

23 PreProposal Conference

Once the project is complete, for how long do you expect to receive assistance from the company? Are we just training staff and that's it, or is there a customer service component for a certain timeframe?

The selected vendor is expected to provide ongoing support to operate and maintain the system in addition to providing scheduling and claims submission support. OHA/OIS does not have staff to maintain and operate the Portal solution.

Revised 09/15/2026, as a result of Question 29.

OHA/OIS does not have staff to maintain and operate the Portal solution.

The selected vendor is expected to operate and maintain the system in addition to providing support for scheduling and claims submission for the life of the portal.

This support will be for portal end users which include clinics, HCIs, CCOs, and OHA (HCI business team, and possibly others depending on who at OHA has access or permissions to request data). It also includes the Recruitment and Retention non-profit vendor responsible for filling last-minute appointments with Oregon-credentialed HCIs before the appointment can go to the selected portal vendor’s ‘overflow’ option to be filled by a non-credentialed HCI. Because claims will be submitted to MMIS and HCIs will be paid via MMIS, OHA Provider Services will be responsible for support regarding payments.

24 Pre Proposal Conference

Can we submit a rough copy (of the proposal) and then update again before the submission date?

Vendors may locate the Bid and submit, or withdraw and resubmit a revised quote (i.e., Proposal) until the Bid Opening Date and time. Once the Bid Opening Date and Time has passed, OregonBuys will not accept quotes (i.e., Proposals).

25 The RFP indicates that HCIs will submit claims through the Portal, that the Portal will perform reimbursement calculations using predetermined rate logic, and that claims will be transmitted to MMIS using X12 EDI. The Project Goals table also references sending payment instructions to multiple payers, including MMIS and CCOs. Please describe the intended end-to-end billing and payment workflow, including which entity calculates, adjudicates, pays, corrects, and reconciles each claim and how the workflow differs for fee-for-service OHP members versus CCO-enrolled members

Potential Payment Workflow

The portal is expected to generate claims for each completed encounter based on appointment details.

• Portal will package encounter information in X12 EDI format and transmit to MMIS, or payment instructions in an approved format to an alternative payer, if appropriate.

• TBD whether Portal will apply rate logic to calculate reimbursement amount prior to submission, or if Portal will send claim details for MMIS to calculate amount owed.

OHP plan enrollment will determine payer:

• If FFS: Transmitted to MMIS

• If CCO: send payment instructions (format

TBD)

(Each will adjudicate and make payment through existing systems.)

It is envisioned that the Portal’s role in the payment process may be limited to transmitting claims or payment instructions and returning payer-generated adjudication statuses – including payment status, denial reasons or other feedback.

26 Is the successful Contractor responsible only for configuring and operating the technology that transmits claims and returns claim status, or must the Contractor also perform claims validation, billing support, rejection correction, reconciliation, dispute resolution, overpayment recovery, or payment administration?

As stated in the RFP, the Contractor’s role will be to provide and operate a web-based SaaS solution that enables integration with the State’s Medicaid Management Information System (MMIS) for claims submission. The Contractor will be responsible for configuring and maintaining the technology that submits claims and returns claim status information.

All claims processing, adjudication, corrections, and financial administration remain under OHA/MMIS or CCO operations and are not part of the Contractor’s scope of work.

27 Attachment A-2 addresses participation by firms certified through Oregon's Certification Office for Business Inclusion and Diversity (COBID). Please clarify the following: (a) Whether COBID-certified participation is evaluated and scored, and if so under which evaluation criterion and with what point allocation -the evaluation table in Section [___] does not identify a separate allocation for it.

(b) Whether this solicitation imposes a mandatory subcontracting requirement or an aspirational participation target under ORS 279A.105, and if so the applicable percentage and the basis on which it is measured (total contract value, labor hours, or another measure).

(c) Whether a Proposer that is itself a certified small or disadvantaged business under another state's program or a federal program - for example a California Department of General Services certified Small Business, or an SBA certification - receives any equivalent recognition, or whether only Oregon COBID certification is recognized for this purpose. (d) Whether a COBID-certified subcontractor must be identified by name, with its certification verified, in the Proposal itself, or whether

(a) -Refer to RFP Section 4.4 for the activities/aspects of the Proposal that are being evaluation in Round 1.

(b) Refer to RFP Section 4.4 for the activities/aspects of the Proposal that are being evaluation in Round 1.

(c) Refer to RFP Attachment A-2 for where to find the definition of an Oregon Certified Firm for purposes of this RFP.

(d) Refer to RFP Attachment A-2 for the information required to be submitted.

(e ) Please see answers in Q#11.

the certified firm may be identified after award. (e) Whether spend on work performed by a COBID-certified subcontractor counts toward any participation requirement on the same basis as certified prime participation.

28 Can you provide a rough estimate of annual number of encounters being managed for all modalities IPI, OPI and VRI including minutes for video and phone? Is there an estimate of growth for the upcoming years?

Please see answers in Q#10.

Group 1 Sept 14

29 OHA/OIS does not have staff to maintain and operate the Portal solution.

From Q#23: Does this imply that the vendor is also required to provide HR resources to manage booking requests and questions from providers, HCI's, etc.

Or is OHA/OIS providing the people to cover this off. Is the expectation that the vendor is providing support to OHA/OIS scheduling team only.

Answer for Q23 has been revised for clarity.

RFP Section 2.5.3, p.

28, Attachment C, p.77

RFP Language: Round 1 price is based on implementation through Go Live plus Year 1. Attachment C separately lists Agency Carried Costs. Question: Are Agency Carried Costs included in the Round 1 evaluated price?

See RFP 2.5.3. The price used for Round 1 Price scoring formula is the “sum costs of initial development and implementation through Go Live plus first full year of operations and maintenance” which include costs the Proposer assumes the agency would carry separately.

For example: Proposal assumes agency will purchase a needed software license from a third party rather than obtain the license by flow-through of the Proposed Solution. The Price Proposal should state this scenario in its assumption AND its assumption of the agency’s cost for obtaining the license in this manner towards the total cost of ownership quote.

File Size What is the maximum file size that may be transmitted via OregonBuys?

OregonBuys has a file size limit of 500 MB for uploading attachments.

However, other internal systems used to distribute materials for evaluation (e.g., email, shared or local drives) may have significantly smaller limits that hinder appropriate distribution, access, and storage of proposals. Including photographic images of subjects that were not asked for, or do not add clarity or are not germane to the RFP’s subject matter, can significantly increase the size of a file without materially improving the content that will be evaluated.

RFP Section 2.5, p.20, c.

RFP Language: Embedding or Linking to Content is Discouraged Question: Would the Government please confirm they will allow hyperlinks in the documents for Table of Contents, Figure/Table references, Section references within the same document.

The “linking” refers to “additional content” (i.e., external of the document). Hyperlinking within the document, such as from a table of contents heading to the location of the content elsewhere in the document, is ok.

33 RFP Section 4 - Attachment E or Attachment F

RFP S-DASOBO-00016280. RFP Section 4 (Contract Redline Exercises) refers to the State's Sample Contract as RFP Attachment F, while the attachment list in RFP Section 1 identifies the Sample Contract as Attachment E and lists no Attachment F. Is the reference to Attachment F an error, or is there an additional document? Prepared with the assistance of Flow AI; reviewed and finalized by the Proposer.

The reference to RFP “Attachment F” in RFP section 4.6.3.f. is incorrect and should say “Attachment E”.

34 Attachment E, Exhibit K-1 not included in posted attachment

RFP S-DASOBO-00016280. Attachment E, Exhibit K, Section 1.5 states that Contractor access to Agency Networks and Systems is subject to Exhibit K-1 and its attachments. Exhibit K-1 does not appear in Attachment E as posted. Will Exhibit K-1 be posted by Amendment during the solicitation period so that Proposers can account for its requirements? Prepared with the assistance of Flow AI; reviewed and finalized by the Proposer.

RFP Attachment E is a sample contract, with the reference to Exhibit K-1 as a placeholder to allow that some specifics may depend on the solution selected.

Therefore, the need and language for this Exhibit, as well as other terms or obligations that appear or do not appear in the sample contract, will be negotiated between the agency and selected proposer.

35 Solution Sizing Can the State provide expected user, provider, interpreter, appointment, claim, and peak-usage volumes for launch and future years? If not, can the State provide a standard baseline and growth estimate?

Please see answers for Q#10. Though we do not expect immediate full portal adoption, we do not have estimates on expected ramp-up rates in portal adoption and usage, or additional baseline data.

Group 2 Sept 16

36 Project Is it correct to state that the contractor will deliver the project turnkey, including quality assurance, DevOps, data migration and so on?

Yes, it is accurate that OHA expects a contractor to deliver a complete project turnkey as a SaaS solution, encompassing quality assurance, testing, data migration, operational support, training and ongoing maintenance. The project management plan should provide details.

37 Migrate Provider data from MMIS (pre-load)

How many Provider records are in scope for the pre-load of provider data from

MMIS?

A pre-load of MMIS data may or may not be part of the selected vendors solution. Scope of that would be determined in the design process if the vendor is expecting data from MMIS as part of their solution.

Additionally, we have an expectation that MMIS data will be collected near real-time via endpoints.

38 Migrate Provider data from MMIS (pre-load)

In what form does the MMIS extract arrive - flat file, database extract, API? Is it possible to get a sample?

If an extract is required from MMIS as part of the Portal solution, the specification for that extract would be determined with the selected vendor. Refer to question #37.

39 Migrate Provider data from MMIS (pre-load)

What is the known data quality of the extract - missing values, duplicates, inactive records, formatting inconsistencies?

If an MMIS extract is requested as part of the proposed solution, data quality would be ascertained once the vendors data request specification has been finalized. Refer to question #37.

40 Integration with State

MMIS:

Is there an MMIS interface specification, companion guide or ICD we can have now?

There is no current interface. Any Portal interface with MMIS would be new and will need to be designed.

41 Integration with State

MMIS:

Is there any MMIS test environment? There are MMIS test environments currently in use.

42 EHR integration layer: Which specific EHR systems, and how many separate provider instances?

Portal integrations with Provider EHR systems are envisioned as part of the Portal solution to support Providers’ access to the Portal. The specific EHRs will be identified in the design process and will be able to access the Portal via endpoints.

43 EHR integration layer: Is the integration one-way (ingest appointment and interpreter need) or two-way (write the assignment back)?

Two-way integration is anticipated. The scope and specific requirements of EHR integrations will be determined in the design phase of the project.

44 EHR integration layer: Is there a sandbox or test EHR instance available?

No, the State currently does not have any EHR integrations.

45 CBA integration: Is there an CBA interface specification, companion guide or ICD we can have now?

It is unclear as to what “CBA ” interface is being referred to.

46 CBA integration: Is display of related rate on the record sufficient, or must rates be applied to claim amounts?

The proposed question is unclear.

47 CBA integration: What is the rate structure - which dimensions apply (credential level, time of day, weekend, holiday, modality, travel, language)?

No final rate structure is currently in place. It is anticipated that the proposer has a solution that can accommodate multiple dimensions.

48 CBA integration: All six personas are listed as viewers - do they all see the same rates, or are rates scoped per payer?

All personas will see the same rates, but rates will vary upon other factors.

49 Build overflow handling when no Registry HCI is available

What is the intended overflow route when no credentialed interpreter is available?

Currently OHA expects the selected Portal vendor to support the overflow needs. Looking to the proposer for a solution.

50 Build overflow handling when no Registry HCI is available

Is the overflow HCI paid through the same claims path, or outside the Portal entirely?

Outside the Portal.

51 Build overflow handling when no Registry HCI is available

Who is accountable for sourcing the overflow interpreter - the Portal, Customer Service staff, or the Provider?

Refer to # 49.

52 Build overflow handling when no Registry HCI is available

Is there an existing process today that we should automate, and can we see it?

No OHA overflow process is in place currently. OHA is looking for to the proposer for solutions.

53 Reporting Export Salesforce reports to Word or PDF

- Salesforce does not support native direct exports to Microsoft Word or Adobe Reader (PDF), so: 1. Is a third-party AppExchange solution acceptable?

2. Which reports must be exportable - all of them, or a defined set? 3. Is PDF sufficient, or is editable Word genuinely required? 4. Expected volume and size -are these a few pages, tens or hundreds?

Looking for the vendors to propose a solution that will satisfy the documented requirements. If a third-party application is part of the proposed solution all costs associated with that application must be included as part of the proposed project costs.

It is expected that any report generated by the final solution would be exportable. Since this is a new system, the volume of reports is not fully confirmed.

It is expected that this will be determined as part of the requirements validation process with the selected vendor.

54 Users How many users of each type (OHA Admin, CCOs, Interpreters, providers, scheduling coordinators) are expected?

Final user counts for each category have not yet been fully enumerated. The exact numbers will be refined during the requirements-validation and design phase with the selected contractor. Generally, OHA anticipates users across the following groups:

• Oregon-credentialed interpreters (see HCI Registry)

• OHA administrative and program staff (estimates ~ 10 users)

• Health care providers and clinic staff (unknown)

• Scheduling coordinators or personnel performing scheduling functions(unknown)

• Coordinated Care Organization (CCO) staff (16 CCOs currently in Oregon)

(Please refer to Question 10 for a sense of volume and use)

55 Attachment B-2 (Claims Management)

Attachment B-2 designates Claims Management, including Claims/EDI X12 837 functionality, as Mandatory. Can these requirements be delivered on a phased timeline post-go-live, or must all Mandatory Requirements be fully operational at initial go-live to be considered Responsive?

All mandatory requirements/features must be included in the portal launch as part of the core solution to go-live.

56 Submission Extension Given the complexity of the requirements across multiple attachments, we request a minimum two-week extension to the proposal submission deadline. Additional time will allow respondents to submit more thorough, accurate, and competitive proposals that better serve the evaluation process.

The Bid Opening date will be/is extended until October 15, 2026. See the General and Summary tabs for this bid.

57 Provider Scheduling Capabilities Relevant section: RFP page 9, Section 2.3, first paragraph; Attach

Will healthcare providers be able to handle the entire scheduling process themselves, or will some steps need to be taken by your customer service team?

The expectation is that providers will be able to manage the entire scheduling workflow directly through the portal.

The Portal Vendor is expected to provide customer service for technical support, along with scheduling and claims support.

58 Assigning Interpreters Relevant section: RFP page 8, Section 2.2, paragraph beginning "The

Can a provider choose a specific interpreter, or does the appointment need to go out to a group of available interpreters? If an interpreter accepts and then cancels, should the appointment automatically become available again?

OHA is looking for a solution that supports both requests for specific interpreters and when a specific interpreter is not requested, the appointment would be distributed to available interpreters (pool).

59 Interpreter Matching Requirements Relevant section:

Attachment B-2, SCH11, SCH15, SCH16 and INT3; R

What information should the system use to match interpreters to appointments?

For example, language, credentials, location, availability and patient preference. Are any of these rules optional?

The expected criteria for matching can include attributes such as language, credential status, gender, specialty, timing/availability, and matching in-person assignments with modality/location constraints. A comprehensive list of matching criteria will be defined during the design phase.

60 On-Demand Interpretation Relevant section: RFP page 8, Section 2.2

Do you need the system to handle requests for an interpreter right away, or is this strictly for scheduling appointments in advance? If immediate requests are required, is there an expected response time?

OHA plans for a core scheduling capability at go-live.

Details of an on-demand workflow (including expected response times and technical support processes) can be defined and scoped during the design phase without delaying project start.

61 Video and Phone Interpretation Relevant section: RFP page 8, Section 2.2, paragraph beginning "The

Can we use an existing platform like Teams, Zoom or Webex for video and phone interpretation, or does that functionality need to be built directly into the portal?

Vendors are welcome to integrate vendor-hosted platforms like Teams, Zoom, or Webex provided the integration. Any cost associated with a third-party vendor must be included in the cost proposal included with submission.

Alternatively, vendors may offer built-in video/phone modules as part of their portal.

62 MMIS Integration Documentation Relevant section: RFP pages 11-12, Section 2.4.3, Data Conversion an

We saw your answer confirming X12 837/835. Will you provide the technical documentation and a test environment for the MMIS integration? Are there separate interfaces for checking patient eligibility and provider information?

Yes. OHA will provide the necessary MMIS technical documentation and access to a test environment to support development and testing of the required X12 837/835 integrations.

OHA will work with the selected vendor to define all required integration points (endpoints), provide documentation, and ensure appropriate test and certification processes are available during the project.

63 HCI Registry Integration Relevant section: RFP page 10, Section 2.3, Table 2, registry synchronize

We saw that the HCI Registry doesn't currently have an API. How do you expect the portal to get interpreter information from the Registry? Will you provide a data file or another way to connect the systems?

To support system integration with the HCI registry, the HCI Registry team is planning on developing an

API.

If the timeline to implement the API does not align with the Portal timeline needs, an alternative method will need to be defined to obtain the Registry data.

The final transfer mechanism and cadence will be finalized during the portal’s design phase.

64 Disputed Appointment Times Relevant section: Attachment B-

2, CLM3, CLM4, CLM5

and CLM7; RFP page

If a provider and interpreter disagree on how long an appointment lasted, what should happen in the portal before the claim is submitted? Does the system need an approval or escalation process?

OHA is looking for a proposer to have solutions to scenarios such as this.

It is expected that the details of the claims processing, the required approvals and the discrepancy processes will be determined in the design process of the Portal.

65 Notification Requirements Relevant section:

Attachment B-2, UX5, UX6 and UX14.

Will email and text messages meet the notification requirements, or do you also need push notifications? Is a mobile app required?

Providers and interpreters should receive secure alerts via email or SMS. Push notifications and a dedicated mobile app may be offered at vendor discretion.

All communication channels should comply with HIPAA and TCPA standards.

66 Implementation and Go-Live Date Relevant section: RFP page 8, Section 2.2, final paragraph; page 16

Is the first quarter of 2028 a firm go-live deadline or an estimated target? Would you consider launching the system in phases?

The Q1 2028 timeframe is an estimated target rather than a fixed deadline. The anticipated vendor implementation timeline runs from June 2027 to September 2028, with an expected go-live in spring/summer 2028.

Refer to question #55

67 System Sizing and User Counts Relevant section: RFP page 9, Section 2.3, first paragraph; page 10, Thanks for providing the estimated appointment volumes. Do you also have estimates for the number of providers, interpreters, OHA staff, CCO users and people using the system at the same time? Can you provide an estimated monthly text-message volume and annual claim volume?

Please see answer to Questions #10 and #54.

68 Interpreter Overflow Requirements Relevant section: RFP page 8, Section 2.2, paragraph describing s

You mentioned that the contractor must provide interpreters when the Registry and Recruitment and Retention partner cannot fill an appointment. Can we use a subcontracted language services company for this? Are there specific qualifications or response times that company would need to meet?

Yes. Vendors may use a subcontracted language services company.

OHA will define specific response-time expectations and coverage requirements during the design phase.

All subcontractors are subject to OHA approval and must comply with the same contractual, operational, and data-security requirements for the overflow work as the primary vendor.

69 CCO payment workflows and interfaces at launch

For CCO-enrolled members, which CCO payment processes must the Portal support at initial go-live? Please clarify whether each CCO uses a different claims or payment-instruction workflow and interface, or whether OHA will provide standardized requirements, data formats, interface specifications, and connectivity for all CCOs. If CCO-specific integrations are required, please identify the CCOs and workflows that must be supported at launch versus those that may be phased in later.

The system will initially support fee-for-service (FFS) OHP members. CCO-related payment processes are not currently defined for the initial implementation.

Specifications for integration with CCOs will be determined during the design phase.

70 Integration roadmap and technical contacts

Please provide a consolidated integration roadmap identifying which external-system integrations are mandatory and fully operational at initial Go-Live, which may be delivered in later phases, and the required timing for each.

For every integration, please also identify whether OHA will provide an existing interface specification or companion guide, a development/test environment with test data, and an OHA or third-party technical point of contact during implementation.

Integration specifications and roadmap will be developed with the selected vendor during the requirements verification and design processes.

71 Day 1 functionality and post-launch phases

Please define the minimum required Day 1 functionality for initial Go-Live versus functionality that may be delivered in post-launch phases. For each major capability-including user onboarding, scheduling and matching, interpreter fulfillment and overflow, claims and payer workflows, integrations, reporting, notifications, customer service, and grievance support-please identify whether it must be fully operational at launch, may be phased in, or is optional, together with any required completion dates and acceptance criteria.

Day 1 functionality must fully support scheduling and claims for FFS members, including core scheduling, interpreter matching, MMIS claims integration, HCI Registry data ingestion, reporting, customer service, and grievance support.

All high-priority requirements are considered MVP for go-live.

Please refer to question #55

All Groups Posted Sept 26

S-DASOBO-00016280 OHA-OHP HCI Portal RFP Q&A