SURS RFI OCMP 27-25703.pdf

Office of Information Technology

Request for Information (RFI) for Surveillance and Utilization Review Subsystem (SURS)

OCMP 27-25703

Issued by

Maryland Department of Health (“MDH” OIG or Medicaid

Issue Date: August 6, 2026

Response Due Date: August 31 and 2:00 pm Local time

Table of Contents

A. Key RFI Information

1. Purpose

2. Issuing Office and Procurement Officer

3. Key Dates B. Background Information

1. Description of Maryland Department of Health

2. Description of Office of the Inspector General for Health (Issuer)

3. Summary of Current System

4. Summary of Current Pain Points

5. Vision for the Future State C. Requested Information

1. Company Information

2. Solution Information

3. Services Information

4. Solicitation Recommendations D. RFI Process and Format

1. Process

2. Contact

3. Due Dates

4. Trade Secrets

5. Response Format

A. Key RFI Information

1. Purpose

The purpose of this RFI, which is not a solicitation to procure, is to gain familiarity with currently marketed products and services for a Surveillance and Utilization Review Subsystem (SURS) for the Maryland Medicaid program. SURS is a federally required component of the Medicaid Management Information System (MMIS) and functions in accordance with federal regulations at 42 CFR Part 433, State Fiscal Administration (specifically Subpart C), 42 CFR Part 455, Program Integrity: Medicaid (specifically §455.1), and 42 CFR Part 456, Utilization Control (specifically §456.1). This RFI contains preliminary information to serve as a platform to initiate discussion with the vendor community. The requirements in this RFI are in no way final and are in no way a representation of that which may be contained in a Request for Proposal (RFP), Invitation for Bid (IFB), Purchase Order RFP (PORFP), Task Order RFP (TORFP) or other procurement vehicle. This issuance does not constitute a commitment to issue a request for bids, award a contract, or pay any costs incurred in preparation of a response to this request. Furthermore, the Issuer requires that all responding vendors abstain from providing any quotes or bids in response to this RFI.

Any information received in response to this RFI will assist the Issuer in collecting information that may be used at a future date for a procurement. A submission in response to this RFI does not guarantee that the respondent will be included in any subsequent procurement. Likewise, a non-submission in response to this RFI does not preclude a recipient or vendor from inclusion in any future procurement.

2. Issuing Office and Procurement Officer

This RFI is being issued by the office listed below. The indicated Procurement Officer is the sole point of contact for this RFI. Please refer all inquiries and submit your response to the Procurement Officer.

1. Agency Marland Department of Health (MDH)

2. Office Office of the Inspector General for Health (OIGH or "Issuer")

3. Location Baltimore, Maryland

4. Procurement Officer Calvin T. Johnson

5. Email mdh.solicitationquestions@maryland.gov

6. eProcurement Home http://news.maryland.gov/dgs/emarylandmarketplace/

7. eProcurement Posting RFI URL Here

3. Key Dates

1. Issued On August 6, 2026

2. Questions Due By August 21 , 2026 at 2:00pm Local Time mailto:mdh.solicitationquestions@maryland.gov

3. Response Due By August 31 , 2026 at 2:00pm Local Time

B. Background Information

1. Description of Maryland Department of Health (MDH)

MDH is the single State Department responsible for operating the Medicaid Program authorized under Title XIX of the Social Security Act. The Medicaid Program serves approximately 1,300,000 enrollees, of which 1,100,000 are enrolled in Managed Care Organizations (MCOs). The Medicaid Program has approximately 70,000 enrolled Providers. The Medicaid Program processes approximately five (5) million FFS claims and 3.5 million MCO encounter data per month. See Section

2.2.1. Since the 1990’s, the Department has been using a system to facilitate the identification of claims for possible fraudulent billing.

2. Description of OIGH (Issuer)

OIGH is an independent office made up of auditors, investigators, compliance officers, data analysts and clinicians dedicated to its mission and serving all Marylanders. Here are primary responsibilities of OIGH:

• Perform audits of MDH programs and health care providers receiving Departmental funds

• Investigate Medicaid providers and recipients to ensure the integrity of the Medicaid Program

• Make recommendations to the Department of Health to improve programmatic vulnerabilities.

• Investigate Medicaid recipients who may be receiving benefits for which they are not eligible.

Federal law requires that every Medicaid program maintains a SURS (Surveillance and Utilization

Review Subsystem) program that performs the following four responsibilities: Safeguard against unnecessary or inappropriate use of Medicaid services and against excess payments. Assess the quality of those services. Provide control for the utilization of all services provided under the plan in accordance with subpart B of the relevant federal regulations. Provide control for the utilization of inpatient services.

The SURS computer program is also used by the Office of the Inspector General for Health. The mission of the Office of the Inspector General for Health (OIGH) is to promote integrity and accountability within the Maryland Department of Health by investigating fraud, waste, abuse of departmental funds, and behavior in the Department that threatens public safety or demonstrates negligence, incompetence, or malfeasance;

3. Summary of Current System

a. Vendor, product, and website

a. Current Product: Since 1990s, Java…. Surveillance and Utilization Review Subsystem

(JSURS), an existing, legacy software application operated by IBM, is used for federally required component of Maryland’s Medicaid Management Information System (MMIS).

b. Current Vendor: IBM

c. Website: Not explicitly listed for the legacy SURS application.

b. Capabilities supported (i.e., business functions or processes)

a. Reporting & Profiling: Generates standard claim reports, .Allows users to create custom reports of specified parameters.

b. Data Store Maintenance: Maintains and updates the SURS Control File, containing adjudicated FFS claims/encounters, MCO encounter data, recipient eligibility, and provider data.

c. User groups / stakeholders supported (including quantities, and if appropriate, indicate if there are organizational structures that impact the user groups / stakeholders)

a. Primary Stakeholder Agency: Maryland Department of Health (MDH) and the Office of the Inspector General for Health (OIGH).

b. Operating Unit: Maryland Department of Health and the Office of the Inspector

General.

c. Supported Stakeholders: Maryland Department of Health and the Office of the

Attorney General for Health, external State agencies, Federal agencies (such as

CMS/OIG), and program leadership.

d. User Quantities & Impacting Structures:

i. System requires access for at least 25 concurrent/unique named users without performance degradation.

ii. Organizational impact includes coordination across FFS and MCO health environments covering ~1,300,000 Medicaid enrollees (~1,100,000 MCO enrollees), ~70,000 enrolled Providers, and ~8.5 million monthly claims/encounters.

d. Key functionality and reports (succinctly summarized)

a. SURS Control File Maintenance: Aggregates and maintains all adjudicated FFS claims, MCO encounters, provider data, and recipient eligibility files.

b. Reporting Functions: * Generates claim reports for State and Federal oversight.

i. Profiling reports by peer groups, CPT utilization, and Drug Utilization.

ii. Ad-hoc statistical queries, statistical summaries, and utilization trend reports.

e. Technical architecture, including method of hosting

Architecture:

a. Data Transmission / File Exchange: Data extracts are transmitted to/from the state via IBM Sterling Connect: Direct using the Secure+ feature. These are legacy MMIS data extracts and flat files.

b. Method of Hosting: On-premises / legacy state data processing architecture including

Microsoft Server 2016.

f. Model for support and maintenance (i.e., the team that supports the current system, whether staff, vendor, and/or contractors)

Shared operational model split between MDH internal staff, MDH MMIS team responsible for creating extracts and IBM responsible for data loading, processing, software maintenance, and system operations.

g. Current system integration points and types (both internal to the agency and with external organizations)

The current SURS relies on batch data extract file layouts received on a monthly cycle via

Connect: Direct.

4. Summary of Current Pain Points

1. Technology Infrastructure at End-of-Support & End-of-Life (EOL)

Legacy System Architecture: The current system, IBM’s JSURS hosted on Microsoft Windows Server 2016 will be reaching end-of-support in Jan 2027 and will not support the updated Microsoft models.

2. Manual Workflows and Fragmented Datasets

• Over-Reliance on Manual Tools: Program Integrity teams historically relied heavily on manual data manipulation and disconnected and external data sets to identify billing errors, claims abuse and potential fraud.

• Isolated Data Silos: Key business processes are split across legacy systems and standalone data sets making cross-functional oversight, lead delivery and audit tracking fragmented and inefficient.

3. Data Volume Overwhelm & Quality Hurdles

• High Transactional Burden: System users are overwhelmed by massive data flows— processing ~5 million Fee-For-Service (FFS) claims and 3.5 million Managed Care Organization (MCO) encounters monthly.

• Lack of Multi-Source Integration: Current tools cannot effectively synthesize or cross-reference Medicaid claim streams with external local, state, and federal datasets.

• Extraction & Formatting Bottlenecks: Ongoing issues with raw data quality, file layouts and extract compatibility require frequent data reloads and heavy ETL/QA intervention.

4. Absence of Advanced Fraud Analytics

• Outdated Detection Methods: Users rely on manual queries without the capacity to program automated algorithms.

• Missing Advanced Capabilities: The existing setup lacks essential technologies like

AI/machine learning, predictive risk scoring, geo-mapping, and visual link analysis needed to uncover multi-party schemes and emerging fraud patterns.

5. Fragmented Case Management & Lead Delivery

• Inflexible Workflow Systems: Lack of a centralized case management tool makes it difficult to track investigations, manage referrals, log overpayment recoveries, and assign tasks across teams.

• Audit & Compliance Vulnerabilities: Disjointed tracking systems historically led to adverse audit findings and complicate responses to state/federal oversight bodies.

6. Critical Federal Certification & Funding Exposure

• Loss of Enhanced Match Rates: Operating an uncertified, non-compliant legacy platform puts MDH at risk of losing enhanced CMS federal funding—dropping operational reimbursement from 75% down to 50%.

• Modular Certification Risks: Failing to transition to a modern, MITA-aligned, cloud-based framework jeopardizes compliance with CMS Streamlined Modular Certification (SMC) requirements.

5. Vision for the Future State

The future state vision for Maryland's Surveillance and Utilization Review Subsystem (SURS) focuses on modernizing the State's Medicaid Program Integrity (PI) framework through advanced analytics, automation, and enhanced modular capabilities.

Key aspects of the SURS future state vision include:

1. Advanced Analytics & Predictive Data Mining

• Data Integration: Modernization of a centralized Data Store that integrates at least six (6) years of historical rolling data across Fee-For-Service (FFS) claims, Managed Care

Organization (MCO) encounters, provider/recipient data, and third-party references.

• Predictive & Machine Learning Models: Implementation of risk-based predictive analytics, AI/machine learning, and pattern analysis to generate high-value, "investigation-ready" leads with low false-positive rates.

• Advanced Visualizations: Advanced graphical tools enabling user-friendly interfaces, link/relationship analysis, entity discovery, trending, and geo-mapping.

2. Flexible & Autonomous Reporting & Algorithms

• Customizable Algorithms: Capability for users to run, build, save, edit, and maintain algorithms for detecting anomalies, billing errors, and overpayments.

• Self-Service & Ad-Hoc Reporting: A robust self-service reporting layer that allows departmental staff to perform complex calculations, manipulate parameters, drill down into claim-level details, and export outputs in multiple standard formats (Excel, PDF, Google

Sheets, etc.).

• Emerging Threat Detection: Proactive detection mechanisms to identify new fraud schemes, disenrolled/penalized providers re-enrolling under alternate entities, and cross-state/Medicare program disqualifications.

3. Comprehensive Vulnerability Assessment & Compliance

• Annual Vulnerability Reviews: Ongoing, structured Program Vulnerability (PV) assessments analyzing payment policies, MCO benefit plan mappings, and FFS/encounter claims to drive systemic improvements and cost avoidance.

• CMS Certification: Full alignment with Centers for Medicare & Medicaid Services (CMS)

Streamlined Modular Certification (SMC) requirements, outcomes, and metrics to maintain enhanced federal funding.

• Interoperability & Standards: Full alignment with the Medicaid Information Technology

Architecture (MITA), HIPAA/HITECH, and Federal/State security and accessibility standards

(e.g., Section 508, ARC-AMPE, NIST 800-53).

4. Enterprise Workflow & Portal Integration

• Integrated Web Portal: Secure, role-based single-point access to reports, algorithms, documentation, and system metrics.

• Dedicated Case Management Tool: An integrated workflow tool capturing FWA tracking, case referrals, automated notifications, document storage, and multi-user collaboration across internal and external designees.

• Provider Education: Continuous tracking and formulation of data-driven recommendations to educate providers on billing compliance and overpayment avoidance.

C. Requested Information

1. Company Information

a. Summary of company location, website, and size.

b. Contact information for the company: Name, title, email, and phone.

c. Brief history of the company.

d. Summary of company's current offerings (products and services).

e. Summary of company's current customer base.

f. Copy of standard brochure / literature about the company, if available.

2. Solution Information

a. Description of marketplace adoption and customer base.

b. Summary of high-level capabilities and modules for the product (i.e., the business functions and processes that are supported).

c. Description of functional capabilities, including selected screenshots of UI.

d. Description of reporting / analytical capabilities, including selected screenshots of actual reports.

e. Description of capabilities or methods for integration and inter-operability with other systems.

f. Description and/or depiction of technical architecture.

g. Description of security and compliance capabilities.

h. Summary of performance benchmarks and success factors.

i. Description of deployment options (typically self-hosted in the Issuer's datacenter or third party-hosted on an outsourcing model (with either the Issuer or the vendor securing arrangements with the third party) or cloud-hosted under a SaaS model)

j. Description of equipment, products, or services required or recommended to enable or complement your product (e.g., printers or barcode readers or third-party data services)

k. Description of approach to patches, maintenance, enhancement requests, and product upgrades.

l. Description of warranties or service level agreements (SLAs).

m. Summary of the model or structure for licensing and pricing (NOT THE PRICING ITSELF, but rather the drivers or components or basis of pricing)

n. Summary of the product roadmap (for which, the Issuer seeks no commitments or guarantees).

o. Location of any resources for reading, training, or demonstrations, if available on the Web.

p. Copy of standard brochure / literature about the relevant product(s), if available.

3. Services Information

a. Description of standard implementation approach and services, including resources and their levels of commitment.

b. Description of training approach, resources, and services.

c. Description of model and resources for product support.

d. Description of preferred or certified partners for integration or support, if any

4. Solicitation Recommendations

Issuer requests respondents to recommend any metrics, documentation, and information that Issuer should furnish bidders in any future solicitation. Respondents should indicate the significance or criticality of that information to the success of either the procurement itself or the subsequent implementation and operation of the solution.

Also, please provide any additional clarifications or recommendations that might be valuable to the Issuer in developing and issuing a future procurement. All input is valued.

D. RFI Process and Format

1. Process

Issuer seeks a written response to this RFI. If the Issuer decides to request presentations or demonstrations ("demos") of respondent solutions, the Issuer will extend opportunity for all RFI respondents to make a presentation or demonstration. Presentations or demonstrations may be either on-site at the Issuer's offices or online via phone and Internet. Any presentation or demonstration is informational only for the purpose of determining feasible solutions and recommendations that could be included in the future procurement. An invitation to present does not indicate that the Issuer is engaged in a pre-selection process for an implementation vendor.

Respondents are not to include pricing information.

2. Contact

Questions and responses shall be submitted in written form to the Procurement Officer:

▪ Name: Calvin T. Johnson

▪ Email: mdh.solicitationquestions@maryland.gov

From the issue date until the response due date for this RFI, respondents shall communicate only with the Procurement Officer, who will engage personnel from Issuer as appropriate.

3. Due Dates

▪ The final deadline for written questions is indicated in Section A of this RFI. No questions will be accepted after that date.

▪ The due date for the response is indicated in Section A of this RFI. Responses are to be sent to the Procurement Officer’s e-mail address as shown in Section A. Responses submitted after the due date may not be reviewed and may preclude invitation for a presentation. The responses to the RFI are to be submitted via e-mail in Microsoft Word or searchable Adobe PDF file format. The subject line in the e-mail submission shall state “Name of Solution RFI Response - RespondentName".

4. Trade Secrets

Respondents should give specific attention to the identification of those portions of its response which it considers confidential, proprietary, commercial information, or trade secrets, and provide justification why such materials, upon request, should not be disclosed by the State under the Public Information Act, Title 4 of the General Provisions of the Annotated Code of Maryland. Respondents mailto:mdh.solicitationquestions@maryland.gov are advised that, upon request for this information from a third party, the Procurement Officer will be required to make an independent determination regarding whether the information may be disclosed.

5. Response Format

The files that should compose your RFI response are:

▪ Transmittal Letter. This file is an MS Word document or Adobe PDF file that is named “RFI # 16-12345 Transmittal RespondentName”. The transmittal letter should be in the form of a standard business letter and should be signed by an authorized individual within the respondent's organization. The transmittal letter should note the following:

- A statement that proprietary information is included, if applicable,

- A statement that the RFI response document is included .

▪ RFI Response Document. This file is an MS Word document or searchable Adobe PDF file that is named “RFI # 16-12345 Response RespondentName”.

- The title page of the response document should specify the RFI name, the RFI number, the company name, and the contact name and title.

- The response document should provide answers to the questions in Section C. The response document should not exceed twenty (20) pages, excluding any associated materials, for example PDF versions of standard marketing materials.

- The response document may include any additional comments, observations, or suggestions that may assist Issuer in drafting any future RFP, IFB, TORFP or other procurement vehicle.

▪ Notice of Proprietary Information. This file, if deemed necessary, is an MS Word document or searchable Adobe PDF file that should contain any confidential information. The file should be named “RFI # OCMP 27-25703-RespondentName - Confidential”. All data within this document should be titled and referenced to the question to which the proprietary information is related.