Request for Solution ACADM.pdf

1 | P a g e Autonomous Coding & Appeals and Denials Management - Request for Solution

Request for Solution (RFS) For

Autonomous Coding and Automated Appeals & Denials Management

1. OVERVIEW & AUTHORITY

The Defense Healthcare Management Systems Modernization (DHMSM) Program Management Office (PMO) intends to award one or more prototype Other Transaction Agreements (OTAs) under 10 U.S.C. § 4022. This competitive process is being conducted as a Request for Solution

(RFS).

Under this RFS, the DHMSM PMO is seeking innovative solutions for two distinct capability offerings:

• Capability 1: Autonomous Coding (AC)

• Capability 2: Automated Appeals & Denials Management (ADM)

These are presented as separate and distinct capability offerings to allow industry partners to propose targeted, highly specialized solutions for either individual capability or both combined.

2. BACKGROUND

The DHMSM PMO is responsible for leading the effort to modernize healthcare delivery across the military health system (MHS). The DHMSM PMO’s core mission is to deliver an integrated, interoperable health information technology solution that enables the MHS to provide high-quality, cost-effective care to service members, veterans, and their families. This is achieved through the deployment and management of a comprehensive EHR, and associated technologies designed to improve patient care, enhance operational efficiency, and support data-driven decision-making throughout the MHS enterprise.

The DHMSM PMO awarded a contract to Leidos in 2015 for the development and deployment of the Department of War electronic health record (DoW EHR). To that end, Leidos teamed with Oracle and other commercial vendors to create MHS GENESIS. Today, the DoW EHR is an Oracle Cerner Millennium product that supports the availability of longitudinal health records for more than 9.6 million DoW beneficiaries and has been deployed to over 137 parent hospitals and clinics with a user base of more than 190,000 Defense Health Agency (DHA) personnel.

3. PROBLEM STATEMENT(S)

The Government seeks primarily non-rules-based, AI/ML-enabled solutions that adapt and improve dynamically based on data patterns, addressing the two interrelated problem areas below.

Additional information regarding each Capability can be found in the attached Statement of Objectives (SOO).

2 | P a g e Autonomous Coding & Appeals and Denials Management - Request for Solution

Capability 1: Autonomous Coding (AC) The Government seeks an autonomous coding capability that uses modern, human-like (AI/ML) computational processes to assign medical billing codes (ICD-10, CPT, HCPCS) from clinical documentation without human intervention, with full auditability and explainability. Traditional coding relies on human coders and is time-consuming, error-prone, and vulnerable to workforce shortages. The Government seeks measurable improvements in operational efficiency, coding accuracy, and cost-effectiveness across outpatient, inpatient, and ancillary environments, and measurable reductions in Discharged-Not-Final-Coded (DNFC) volume and Accounts Receivable (A/R) days.

Capability 2: Automated Appeals & Denial Management (ADM) The Government maintains significantly backlogged aged A/R across multiple systems, creating risk to accurate GAAP-compliant financial reporting and limiting timely recovery of funds denied by Other Health Insurance (OHI) / third-party payers. Existing manual appeals and denials processes are labor-intensive and unable to resolve multi-year aged receivables at scale. The Government requires a phased, automated solution that improves first-pass claim success, accelerates documentation release, and enhances appeals and denials management to increase recoupment and reduce aged A/R. The solution shall not autonomously write off, adjust, or otherwise financially dispose of any claim; all financial dispositions shall require human approval; and every automated action shall carry a complete, FFMIA-aligned audit trail.

4. CALL FOR WHITE PAPER SUBMISSIONS

Interested companies may submit White Paper(s) to address either the AC capability, the ADM capability, or both (AC & ADM). Companies proposing both capabilities must submit two separate white papers, one per capability. All white paper submissions must follow the below guidelines.

4.1. General Submission Guidelines (Applies to ALL submissions)

• Submission Format: Unnecessarily elaborate brochures or proposals are not desired. Do not include resumes for any personnel. All submissions shall be unclassified.

• Page Limits & Structure: White paper submission should not exceed ten (10) written pages for each Capability. If you are submitting for both capabilities, you must submit two separate and distinct white papers (up to 10 pages each). Combined submissions in a single file will not be accepted. The cover page, the Bill of Materials (BOM), and any addenda identified in this RFS do not count against the ten-page limit. Submissions shall be provided in PDF format and named using the convention {Company Name} {Capability}White Paper.

• Specificity & Evidence: Be specific in the description of the proposed solution and, where specific software or the approach has been successfully leveraged, provide real-world examples. Diagrams or figures to depict the proposed solution are encouraged and companies may provide links to public websites with such information.

3 | P a g e Autonomous Coding & Appeals and Denials Management - Request for Solution

• Cover Page: Create a cover page that identifies the capabilities being proposed against, the solicitation number, the name(s) of the company(ies), website(s), point(s) of contact, and contact information (email address, phone number and mailing address).

• Non-Traditional Contractor: Identify whether each company listed on the cover page is a non-traditional defense contractor as defined in 10 U.S.C. 3014 or a non-profit research institution. (In short, a non-traditional defense contractor is an entity that has not received a full Cost Accounting Standards covered contract from the Federal Government within a 12-month period prior to the issuance of this solicitation.) This information should not take more than a page to provide and will not be used to determine which solutions are chosen for the next step of the review process.

• Addendum 1: Licensing Terms: Include known licensing terms (end-user licensing agreements) for software/technology included in the approach as well as any other terms and conditions (for example, for services) that the submission would rely upon.

References to existing Federal Government contracts with appropriate terms that could be used to streamline negotiations are encouraged. Hyperlinks will not be accepted.

• Addendum 2: Confidentiality: If there are any concerns about sharing information in your white paper with Leidos and Oracle Health, companies must include a restrictive marking on each relevant page identifying such limitations, as well as a paragraph explaining the concern. To protect business plans and technical information from FOIA disclosure for a period of five years, companies are required to include a legend on the documents identifying them as being submitted on a confidential basis.

5. WHITE PAPER CONTENT

The white paper will address each proposed capability and include the required details outlined below, as applicable.

4 | P a g e Autonomous Coding & Appeals and Denials Management - Request for Solution

5.1. Core Technical & Compliance Requirements (Applies to ALL submissions)

5.1.1. EHR Architecture Experience: Describe any experience integrating your solution with an electronic health record (EHR). Leidos is the current system integrator for MHS GENESIS. The Government anticipates the successful offeror will collaborate with Leidos to integrate the solution into MHS GENESIS.

5.1.2. Advanced Documentation, Automation, and Decision Support: Describe the solutions support capabilities that utilize modern, human-like, computational processes.

The response should address the approach to mitigating potential bias within these processes to ensure fairness and accuracy in code assignment across patient populations.

Furthermore, describe the plan for ongoing monitoring and evaluation of system performance to identify and correct any errors or biases.

5.1.3. DoW EHR Data Required to Generate the Coding: Describe how long the company’s solution requires data to be retained to generate the coding, and whether the data retention time can be adjusted to suit the Government’s requirements.

5.1.4. Security & Compliance:

• Describe how the proposed solution complies with DODI 8510.01, Risk Management

Framework (RMF) for DoW IT and complies with annual Federal Information Security Modernization Act (FISMA) security control testing.

• Identify whether the solution has obtained or when it is anticipated to obtain FedRAMP authorization at the moderate level. The solution must possess, at a minimum, a valid DoD IL 4+ authorization (DoD IL 5 is preferred). This can be attained through a FedRAMP High authorization or a FedRAMP Moderate authorization with additional Privacy Overlays applied. During prototype project performance, DHA will utilize the FedRAMP authorization to issue a mission owner authorization.

• The contractor shall obtain and maintain access to the Supplier Performance Risk System (SPRS) via the PIEE, (available via the internet at https://www.sprs.csd.disa.mil/). If a group of companies is submitting a white paper, or any subcontractor(s) are contemplated, provide the status of the current assessment posted in SPRS for each.

• Provide the status of CMMC Level 2 (self-attestation) for the company (or companies if a group) and any subcontractor(s) that will be managing CUI.

• Confirm ability to comply with the incident management requirements of Chairman of the Joint Chiefs of Staff Manual (CJCSM) 6510.01B “Cyber Incident Handling Program”.

• Confirm compliance with the Health Insurance Portability and Accountability Act (HIPAA) of 1996.

• Ability to encrypt data at rest and in transit.

• Ability to support Common Access Card/Personal Identify Verification (CAC/PIV) authentication.

• Address whether the source code is held in the United States and whether other than

United States citizens access, maintain or upgrade the software.

https://www.sprs.csd.disa.mil/

5 | P a g e Autonomous Coding & Appeals and Denials Management - Request for Solution

• Ability to accept the terms of the DHA BAA (available online at https://health.mil/Reference-Center/Policies/2022/01/06/HIPAA-Compliant- Business-Associate-Agreement).

5.2. Solution Support Details (Applies to ALL submissions):

• Bill of Materials (BOM): For each capability, vendors will submit a high-level BOM.

The BOM should provide a rough, top-level summary of the major components, software modules, tools, data sources, licenses, hosting, AI tokens, or services required to deliver the proposed solution.

• Relevant Experience: Briefly describe relevant prior experience developing, deploying and sustaining similar (in scope, scale, and technical complexity) solutions. Identify where your solution has been implemented and specify your organization's role in these efforts, including whether you acted as the primary vendor or a supporting partner.

• Project Management: Explain your organization's project management expertise and methodology and organization's risk management capabilities and approach

• Collaboration: Vendors should clearly indicate whether they are collaborating with any other organization to deliver the proposed solution. If collaboration is planned, identify each participating organization and briefly describe its role and contribution.

• Data Rights, Intellectual Property, and Engine Provenance: Identify the underlying coding or denials engine proposed, whether the offeror owns or licenses it, and the offeror’s rights to maintain, patch, and retrain it over a multi-year production period.

Cleary explain whether the engine has processed real (non-synthetic) clinical documentation at a scale and specialty mix comparable to this effort. Vendors must describe the data rights proposed for the trained model, tuned model parameters, and any Government-derived datasets.

5.3. Content for Capability 1: Autonomous Coding (AC)

• Covered medical services and care environments (e.g., inpatient, outpatient, specialty care, ancillary, etc.).

• Ability to code institutional and professional encounters per care environment.

• Percentage of encounters successfully coded and placed in a final coded state (projected at start and at 3, 6, 9, and 12-month intervals). For this purpose, an encounter is “final coded” when the solution assigns a complete code set and applicable modifiers sufficient for claim submission and releases the encounter without human intervention, with an audit trail traceable to the source documentation. Coverage shall be expressed against total in-scope encounters. Identify any encounter volume the solution would exclude from autonomous coding, the basis for exclusion, and the resulting exclusion rate.

• Code selection and assignment accuracy, and how accuracy is measured.

• Impact on denial rates and appeal success rates.

• Examples of time and cost savings achieved through automation.

• Methods used to measure accuracy.

https://health.mil/Reference-Center/Policies/2022/01/06/HIPAA-Compliant-Business-Associate-Agreement https://health.mil/Reference-Center/Policies/2022/01/06/HIPAA-Compliant-Business-Associate-Agreement

6 | P a g e Autonomous Coding & Appeals and Denials Management - Request for Solution

• Process and user interface for validating, editing and auditing coding results that should include an audit and Clinical Documentation Improvement (CDI) trail for each code assigned per encounter.

5.4. Content for Capability 2: Automated Appeals & Denials Management (ADM)

• How the proposed solution leverages modern, human-like, computational processes to automate the generation and submission of appeals to third-party payers, including the workflow, decision logic, and supporting data sources.

• How the solution proactively reduces future denials by optimizing coding accuracy, tuning autonomous coding functionality, and/or implementing configurable enterprise-level business rules.

• How the solution measures and reports payer performance through dashboards, scorecards, or defined key performance indicators.

• Any built-in auditing capabilities that quantify the financial impact of denials, appeals, and recovered revenue. Include information on reporting outputs, traceability, and how insights support leadership decision-making and audit readiness.

• How solution performance is measured on realized outcomes rather than activity — specifically, how appeals credited to the solution are tied to claims actually collected or overturned rather than appeals generated — and how recovery is reported in dollars against the billable third-party / Other Health Insurance population over a defined measurement window.

• How the solution ranks denied, recoverable claims by expected recovery value, and the evidence that the ranking outperforms a chronological or random baseline. Describe how predicted resolution outcomes are validated against actual outcomes.

6. PHASED EVALUATION APPROACH

This RFS is leveraging a multi-phased approach, consisting of three phases as outlined below:

Phase 1: White Papers

Interested parties should submit white papers in accordance with the instructions in Sections 4 and 5. The Government will evaluate each white paper against the applicable problem statement(s) to determine whether the proposed solution demonstrates sufficient merit.

Companies whose white papers are determined to have sufficient merit will be invited to participate in Phase 2.

Phase 2: Team Discussion

During this phase the Government will have the opportunity to ask questions, seek additional details, and gain a deeper understanding of the proposed solution, technical approach, and implementation considerations. This phase is intended to facilitate interactive dialogue between the Government evaluation team and the interested company. After discussions, vendors will provide a cost breakdown of the prototype project, to include a pricing estimate for

7 | P a g e Autonomous Coding & Appeals and Denials Management - Request for Solution implementation of production. Further instructions will be provided to invited companies.

Companies who are determined to have sufficient merit in addressing the problem statement and a sound technical approach will be invited to participate in Phase 3.

Phase 3: Live Demonstration

During this phase, companies will conduct a live demonstration of their proposed solution. The demonstration shall use vendor provided sample data set and must showcase the solution(s) in its entirety, including core functionality, key capabilities, and performance relevant to the problem statement(s). Further instructions regarding the live demonstration process, evaluation criteria, format, duration, and logistics will be provided to invited companies.

7. DOWN-SELECT

The Government may down-select between phases and reserves the right to limit the number of vendors invited to participate in each subsequent phase. Vendors who are not selected to advance will be notified that they will not be invited to participate in the next phase.

The Government reserves the right to retain certain vendors who successfully complete one or more phases in a pool for possible later consideration under this RFS. For example, an offeror that is not selected to advance after Phase 2 may still be retained if the Government determines that the proposed solution has merit and may warrant further consideration if higher-ranked solutions do not meet the Government’s needs.

8. AWARD

The Government reserves the right to award multiple agreements, or make no award at all, resulting from this RFS. At its discretion, the Government may make awards for whole solutions, or partial components thereof.

9. SUBMISSION INSTURCTIONS

Questions regarding this RFS must be submitted via email to the individuals listed below no later than August 13, 2026 10:00 AM ET. The Government intends to publish consolidated responses to all timely questions received.

White paper submissions must be emailed to the below individuals no later than August 19, 2026 01:00 PM ET. The Government is under no obligation to review submissions that arrive after this date and time and may not consider late submissions.

• Sharjeel Javaid sharjeel.j.javaid.civ@health.mil mailto:sharjeel.j.javaid.civ@health.mil

8 | P a g e Autonomous Coding & Appeals and Denials Management - Request for Solution

• Dominique Brown Dominique.u.brown.civ@health.mil

The Government will not pay for costs associated with the preparation or submission under this

RFS.

10. ATTACHMENTS

1. Statement of Objectives (SOO): The attached SOO is being provided for awareness and to promote transparency into the process; however, it is only a draft SOO and is subject to change at the Government’s discretion.

mailto:Dominique.u.brown.civ@health.mil