STATE OF SOUTH DAKOTA DEPARTMENT OF SOCIAL SERVICES DIVISION OF MEDICAL SERVICES

Interoperability and Patient Access

1.    Scope of Work

DSS is seeking a qualified individual with a cost-effective solution that can implement and support the health plan’s requirements described in the CMS Interoperability and Patient Access Final Rule (CMS-9115-F) and 2024 CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F). The Final Rules require health plans serving Medicaid, Medicare Advantage, and the Federally Facilitated Exchanges to implement extensive mandates to share health information at the direction and approval of enrolled members, with third party SMART on FHIR applications in a more accessible and timely manner. The solution must be flexible enough to support future business requirements and regulatory changes, specifically regarding patient data access and interoperability outlined in CMS-9115-F and CMS-0057-F and associated CMS released guidance, FAQs, and Companion Guides.

Minimum Functional Requirements Patient Access API

·       Solution is compliant with the Patient Access API described in CMS Interoperability and Patient Access Final Rule.

·       FHIR API System Requirements

o   Cloud-hosted FHIR API server supporting FHIR version 4.0.1 or greater protocol.

·       Façade data model served to each client via the FHIR protocol and data model.

·       Makes available source data for claims, encounters, clinical data (based on USCD1 v1+) and drug formulary data using publicly available implementation guides such as (CARIN IG for Blue Button IG, US Core IG, Da Vinci IG)

·       Data Maintenance Timeframes

o   Drug formularies are updated monthly no later than thirty calendar days.

o   Data for claims, encounters, and clinical data are available no later than one business day after receipt.

o   Drug benefit data, no later than one business day after the effective date of any such information or updates to such information.

o   Applicable to recipients with a date of service on or after January 1, 2016 and are active members.

·       99.9% Systems Availability

·       A fully documented API

·       A documented plan for ongoing maintenance and operations

Provider Access API

·       Solution is compliant with the Provider Access API described in CMS Interoperability and Prior Authorization Final Rule.

·       FHIR API System Requirements

o   Cloud-hosted FHIR API server supporting FHIR version 4.0.1 or greater protocol.

·       Façade data model served to each client via the FHIR protocol and data model.

·       Makes available source data for claims, encounters, clinical data (based on USCD1 v1+) and drug formulary data using publicly available implementation guides such as (CARIN IG for Blue Button IG, US Core IG, Da Vinci IG)

·       Data Maintenance Timeframes

o   Data for claims, encounters, and clinical data are available no later than one business day after receipt.

o   Applicable to recipients with a date of service on or after January 1, 2016 and are active members.

·       99.9% Systems Availability

·       A fully documented API

·       A documented plan for ongoing maintenance and operations

Payer-to-Payer API

·       Solution is compliant with the Payer-to-Payer API described in CMS Interoperability and Prior Authorization Final Rule.

·       FHIR API System Requirements

o   Cloud-hosted FHIR API server supporting FHIR version 4.0.1 or greater protocol.

·       Façade data model served to each client via the FHIR protocol and data model.

·       Makes available source data for claims, encounters, clinical data (based on USCD1 v1+) and drug formulary data using publicly available implementation guides such as (CARIN IG for Blue Button IG, US Core IG, Da Vinci IG)

·       Data Maintenance Timeframes

o   Data for claims, encounters, and clinical data are available no later than one business day after receipt.

o   Impacted payers are only required to share patient data with a date of service within five years of the request for data.

·       99.9% Systems Availability

·       A fully documented API

·       A documented plan for ongoing maintenance and operations

Consent and Identity Management

·       Obtain member consent of third-party SMART on FHIR applications and ability for each member to view, track, and modify their consent.

·       Ability to integrate with existing Medical Services portal and data warehouse.

·       Ability to support identity verification and authentication via OAuth 2+ and OpenID Connect 1+ incorporating errata set 1.

·       Support SMART on FHIR authorization process (Application Launch Framework Implementation Guide Release 1.0.0) for secure authorization of third-party application access to the Patient Access API, Provider Access API, and Payer-to-Payer API.

·       Customer service support for member questions and troubleshooting.

Third-party Support for SMART on FHIR Application

·       Registration and onboarding process for third-party applications to connect to the Patient Access API.

·       Creation and maintenance of publicly accessible API documentation.

·       Third-party attestation process that obtains information about a third-party application’s privacy policy and shares that information with members.

·       Security risk assessment of third-party applications to evaluate and approve access to members Patient Access API, Provider Access API, and Payer-to-Payer API.

·       Ability for Medical Services administrators to revoke or discontinue API access for members.

·       Customer service and support for third-party developer questions and troubleshooting.

·       Dedicated developer portal or “sandbox” for third-party developers to test with sample data.

Technical Support and Training

·       DSS anticipates the team will require training during implementation and as needed to support staff transition and new features as part of product enhancements.

o   Ability to provide initial training and ongoing as requested.

o   Offer technical support and training for the platform, modules, and user provisioning options.

o   Provide self-service training materials covering core system functionality and reporting (e.g., PowerPoint Slides, recorded webinars).

System Maintenance

·       The selected vendor will be responsible for ongoing system maintenance and operations.

o   The vendor will be expected to make software improvements for the duration of the contract to maintain compliance with all federal and state regulations.

o   Provide ongoing technical support for the solution.

o   Provide incident and error reporting on the system.

o   Provide access to a test system for DMS staff to test enhancements prior to production release.

Account Management

·       A primary point of contact will help support the day-to-day operations of the system, including issue escalations and solutions. The account manager will work closely with DSS and Medical Services staff to ensure that the system supports the workflows and needs of Department and Division.

o   Provide contract oversight and issue escalation and resolution.

o   Maintain a log of enhancements and resolutions that can be used to prioritize future implementation needs.

Implementation Services

·       DMS will partner with the selected vendor to

o   Prepare a project plan and schedule.

o   Develop business, reporting and technical requirements. Selected vendor is expected to utilize a requirement traceability matrix (RTM) to capture and track all requirements.

o   Establish connectivity to the solution.

o   Develop a test plan and execute system/integration testing, including user acceptance criteria and testing prior to go-live.

o   Selected vendor will assign a dedicated project manager throughout the execution of the project lifecycle.

o   In cooperation with DSS project manager, vendor project manager will manage and support risks and issues, communication plans, meeting minutes, change control, and solution implementation.

2.  Project Location:

It is anticipated that 25% of work will be performed on-site in Pierre, South Dakota subject to needs. DSS will provide office space for the successful vendor while on-site in Pierre, South Dakota.

3.    Work Order Duration:

The duration of this work order is expected to last 12 months commencing on or about June 1, 2026, and ending May 31, 2027, with the option to renew for up to two (2) one (1) year contracts. Extension of the work order beyond these term will be at the discretion of the State based on performance and/or continued availability of funds.

This amendment may be terminated by either party hereto upon thirty (30) days written notice. Upon termination of this amendment, all accounts and payments shall be processed for services rendered to date of termination.

STATE OF SOUTH DAKOTA DEPARTMENT OF SOCIAL SERVICES DIVISION OF MEDICAL SERVICES

Interoperability and Patient Access

1.    Scope of Work

DSS is seeking a qualified individual with a cost-effective solution that can implement and support the health plan’s requirements described in the CMS Interoperability and Patient Access Final Rule (CMS-9115-F) and 2024 CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F). The Final Rules require health plans serving Medicaid, Medicare Advantage, and the Federally Facilitated Exchanges to implement extensive mandates to share health information at the direction and approval of enrolled members, with third party SMART on FHIR applications in a more accessible and timely manner. The solution must be flexible enough to support future business requirements and regulatory changes, specifically regarding patient data access and interoperability outlined in CMS-9115-F and CMS-0057-F and associated CMS released guidance, FAQs, and Companion Guides.

Minimum Functional Requirements Patient Access API

·       Solution is compliant with the Patient Access API described in CMS Interoperability and Patient Access Final Rule.

·       FHIR API System Requirements

o   Cloud-hosted FHIR API server supporting FHIR version 4.0.1 or greater protocol.

·       Façade data model served to each client via the FHIR protocol and data model.

·       Makes available source data for claims, encounters, clinical data (based on USCD1 v1+) and drug formulary data using publicly available implementation guides such as (CARIN IG for Blue Button IG, US Core IG, Da Vinci IG)

·       Data Maintenance Timeframes

o   Drug formularies are updated monthly no later than thirty calendar days.

o   Data for claims, encounters, and clinical data are available no later than one business day after receipt.

o   Drug benefit data, no later than one business day after the effective date of any such information or updates to such information.

o   Applicable to recipients with a date of service on or after January 1, 2016 and are active members.

·       99.9% Systems Availability

·       A fully documented API

·       A documented plan for ongoing maintenance and operations

Provider Access API

·       Solution is compliant with the Provider Access API described in CMS Interoperability and Prior Authorization Final Rule.

·       FHIR API System Requirements

o   Cloud-hosted FHIR API server supporting FHIR version 4.0.1 or greater protocol.

·       Façade data model served to each client via the FHIR protocol and data model.

·       Makes available source data for claims, encounters, clinical data (based on USCD1 v1+) and drug formulary data using publicly available implementation guides such as (CARIN IG for Blue Button IG, US Core IG, Da Vinci IG)

·       Data Maintenance Timeframes

o   Data for claims, encounters, and clinical data are available no later than one business day after receipt.

o   Applicable to recipients with a date of service on or after January 1, 2016 and are active members.

·       99.9% Systems Availability

·       A fully documented API

·       A documented plan for ongoing maintenance and operations

Payer-to-Payer API

·       Solution is compliant with the Payer-to-Payer API described in CMS Interoperability and Prior Authorization Final Rule.

·       FHIR API System Requirements

o   Cloud-hosted FHIR API server supporting FHIR version 4.0.1 or greater protocol.

·       Façade data model served to each client via the FHIR protocol and data model.

·       Makes available source data for claims, encounters, clinical data (based on USCD1 v1+) and drug formulary data using publicly available implementation guides such as (CARIN IG for Blue Button IG, US Core IG, Da Vinci IG)

·       Data Maintenance Timeframes

o   Data for claims, encounters, and clinical data are available no later than one business day after receipt.

o   Impacted payers are only required to share patient data with a date of service within five years of the request for data.

·       99.9% Systems Availability

·       A fully documented API

·       A documented plan for ongoing maintenance and operations

Consent and Identity Management

·       Obtain member consent of third-party SMART on FHIR applications and ability for each member to view, track, and modify their consent.

·       Ability to integrate with existing Medical Services portal and data warehouse.

·       Ability to support identity verification and authentication via OAuth 2+ and OpenID Connect 1+ incorporating errata set 1.

·       Support SMART on FHIR authorization process (Application Launch Framework Implementation Guide Release 1.0.0) for secure authorization of third-party application access to the Patient Access API, Provider Access API, and Payer-to-Payer API.

·       Customer service support for member questions and troubleshooting.

Third-party Support for SMART on FHIR Application

·       Registration and onboarding process for third-party applications to connect to the Patient Access API.

·       Creation and maintenance of publicly accessible API documentation.

·       Third-party attestation process that obtains information about a third-party application’s privacy policy and shares that information with members.

·       Security risk assessment of third-party applications to evaluate and approve access to members Patient Access API, Provider Access API, and Payer-to-Payer API.

·       Ability for Medical Services administrators to revoke or discontinue API access for members.

·       Customer service and support for third-party developer questions and troubleshooting.

·       Dedicated developer portal or “sandbox” for third-party developers to test with sample data.

Technical Support and Training

·       DSS anticipates the team will require training during implementation and as needed to support staff transition and new features as part of product enhancements.

o   Ability to provide initial training and ongoing as requested.

o   Offer technical support and training for the platform, modules, and user provisioning options.

o   Provide self-service training materials covering core system functionality and reporting (e.g., PowerPoint Slides, recorded webinars).

System Maintenance

·       The selected vendor will be responsible for ongoing system maintenance and operations.

o   The vendor will be expected to make software improvements for the duration of the contract to maintain compliance with all federal and state regulations.

o   Provide ongoing technical support for the solution.

o   Provide incident and error reporting on the system.

o   Provide access to a test system for DMS staff to test enhancements prior to production release.

Account Management

·       A primary point of contact will help support the day-to-day operations of the system, including issue escalations and solutions. The account manager will work closely with DSS and Medical Services staff to ensure that the system supports the workflows and needs of Department and Division.

o   Provide contract oversight and issue escalation and resolution.

o   Maintain a log of enhancements and resolutions that can be used to prioritize future implementation needs.

Implementation Services

·       DMS will partner with the selected vendor to

o   Prepare a project plan and schedule.

o   Develop business, reporting and technical requirements. Selected vendor is expected to utilize a requirement traceability matrix (RTM) to capture and track all requirements.

o   Establish connectivity to the solution.

o   Develop a test plan and execute system/integration testing, including user acceptance criteria and testing prior to go-live.

o   Selected vendor will assign a dedicated project manager throughout the execution of the project lifecycle.

o   In cooperation with DSS project manager, vendor project manager will manage and support risks and issues, communication plans, meeting minutes, change control, and solution implementation.

2.  Project Location:

It is anticipated that 25% of work will be performed on-site in Pierre, South Dakota subject to needs. DSS will provide office space for the successful vendor while on-site in Pierre, South Dakota.

3.    Work Order Duration:

The duration of this work order is expected to last 12 months commencing on or about June 1, 2026, and ending May 31, 2027, with the option to renew for up to two (2) one (1) year contracts. Extension of the work order beyond these term will be at the discretion of the State based on performance and/or continued availability of funds.

This amendment may be terminated by either party hereto upon thirty (30) days written notice. Upon termination of this amendment, all accounts and payments shall be processed for services rendered to date of termination.