CMS releases Section 111 NGHP User Guide (Version 8.2)

By Mark Popolizio, J.D., Jeremy Farquhar

November 20, 2025 / 16 min read

On November 18, 2025, the Centers for Medicare and Medicaid Services (CMS) released an updated Section 111 NGHP User Guide (Version 8.2, October 6, 2025) regarding Section 111 reporting related to non-group health plans (NGHPs) (liability, no-fault and workers’ compensation).

CMS S111 NGHP Blog Image with people standing and smiling

As usual, CMS lists the new updates in the beginning of each User Guide chapter in a “Summary” page. In reviewing these pages, CMS indicates that it has made changes to Chapter III (Policy), Chapter IV (Technical Information), and Chapter V (Appendices).

Summary of Key Updates

Overall, while CMS has made several changes to various reporting aspects as outlined more fully in the succeeding sections, we start with following three key updates of likely interest and significance:

CMS has added guidance for reporting a single settlement resolving multiple incidents (different Dates of Incident) with one TPOC. In this situation, CMS states that the RRE shall report the earliest date of incident and include all diagnosis codes being settled for all dates of incident, regardless of the timing of the subsequent dates of incident, the nature of the injuries, or any allocation made to each date of incident in the settlement documents. In essence, this means that a single settlement, judgment, award or other payment resolving multiple claims/incidents should result in a single TPOC report as opposed to separate TPOC reports for each of the claims/incidents being resolved. In the authors’ experience, CMS has provided this guidance informally for quite some time, with the agency now memorializing this guidance in its User Guide.
CMS has also added new guidance regarding WCMSA reporting where a single MSA is established based on a TPOC which resolves multiple claims/incidents. In this situation, CMS states that it is the earliest date of incident that must be reported, if only one TPOC is made. If multiple TPOCs are submitted, but only one MSA is reported, the MSA shall be reported on the first TPOC only. Where there are multiple defendants (RREs) reporting in this scenario, the same guidance applies to MSAs as it does to TPOCs.
CMS’s updates also provide clarification regarding multiple settlements involving the same individual. In this situation, CMS clarifies that the records shall reflect each RRE’s unique TPOC amount and not the aggregate TPOC the beneficiary will be receiving, the latter being how the verbiage in the prior User Guide section was often interpreted.

Additional detail regarding each of these updates, along with an outline of CMS’s several other updates, are broken down by Chapter below as follows:

Chapter III Updates

CMS states in the Summary of Changes page in Chapter III as follows: “Language has been updated to clarify different situations where it may be appropriate to submit multiple records for a single individual (Section 6.5.1.3).”^[1]As noted below, as part of these updates, CMS has added guidance for two new reporting situations.

The Chapter III updates are summarized as follows:

NEW - Single settlement resolving multiple incidents (different Dates of Incident)

As noted in the Summary of Key Updates above, CMS has added new guidance regarding situations where there is a single settlement resolving multiple incidents (with different dates of incident) stated, in full, as follows:

Single settlement resolving multiple incidents (different Dates of Incident) - Where there are multiple incidents (multiple dates of incident) being resolved with one TPOC, the RRE shall report the earliest date of incident and include all diagnosis codes being settled for all dates of incident. This applies regardless of the timing of the subsequent dates of incident, the nature of the injuries, or any allocation made to each date of incident in the settlement documents. This ensures that all medicals that were released by the settlement are accurately recovered while still affording the beneficiary a dispute and administrative appeal process if any claims are erroneously identified.^[2]

The above update is notable as this is feedback that CMS has often provided informally when responding directly to questions from Section 111 reporters for quite some time now. However, in the authors’ experience, this is something about which there has reportedly been considerable confusion and there have been conflicting understandings of appropriate reporting guidelines in these scenarios due to the prior lack of specific published guidance. From the authors’ point of view, this is a very important update which should hopefully help to eliminate the significant confusion and conflicting understandings of appropriate reporting guidelines in these scenarios. Ultimately, as outlined in CMS’s new language above, what this boils down to, in essence, is that a single settlement, judgment, award or other payment resolving multiple claims/incidents should result in a single TPOC report as opposed to separate TPOC reports for each of the claims/incidents being resolved.

NEW - Medicare Set-Asides (multiple dates of incident)

As also noted in the Summary of Key Updates section, CMS added new guidance regarding workers’ compensation Medicare set-aside reporting where a single Medicare set-aside is established based on a settlement, judgment, award or other payment (TPOC) which resolves multiple claims/incidents.

On this point, CMS’s new update states, in full, as follows:

Medicare Set-Asides - As it relates to multiple dates of incident, an MSA, if applicable, shall be reported under the same guidance as above. That is, the earliest date of incident, if only one TPOC is made. If multiple TPOCs are submitted, but only one MSA is reported, the MSA shall be reported on the first TPOC only. Where there are multiple defendants (RREs) reporting in this scenario, the same guidance applies to MSAs as it does to TPOCs.^[3]

Similar to the newly published guidance regarding reporting of TPOC when a single settlement, judgement, award or other payment resolves multiple claims/incidents, this is also helpful clarification from the author’s view. That said, one element of the above new passage which seems to be slightly confusing, from the authors’ perspective, is the sentence that reads, “If multiple TPOCs are submitted, but only one MSA is reported, the MSA shall be reported on the first TPOC only.”^[4] In this regard, the aspect the authors find confusing, and will likely require further explanation from CMS, is that the reporting guidance in relation to single TPOCs resolving multiple claims/incidents specifically instructs RREs not to submit multiple TPOCs for each claim/incident but then CMS indicates that if multiple separate TPOC reports are submitted, that the MSA information should only be included within the TPOC report in connection to the earliest date of incident. At present, it seems somewhat unclear if CMS may have some alternate type of scenario in mind when making this reference. It will be interesting to see if CMS provides any additional clarification on this front.

Multiple settlements involving the same individual

Expanding on the information contained in the Summary of Key Updates section above, CMS also made some wording changes to Section 6.5.1.3 regarding “Multiple settlements involving the same individual.” The specific new changes contain what could be viewed as more specific guidance regarding situations where there are multiple TPOCs submitted for same individual, for the same incident, being reported by different RREs.

Specifically, in the above situation, the prior version of Section 6.5.1.3 reads as follows: “Each RRE must report appropriately. If there will be multiple records submitted for the same individual but coming from different RREs they will be cumulative rather than duplicative.”^[5]

In comparison, the new updates to Section 6.5.1.3 change the above to read as follows (with the authors underlining the pertinent new verbiage for easier identification): “If there will be multiple TPOCs submitted for the same individual, for the same incident, but reported by different RREs, the records shall reflect each RRE’s unique TPOC amount and not the aggregate TPOC the beneficiary will be receiving. If more than one RRE has assumed responsibility for ongoing medicals, Medicare would be secondary to each such entity.”^[6]

In terms of significance, the new verbiage can be viewed as clarifying that in this situation each RRE is to report its specific TPOC amount – not the aggregate TPOC amount the claimant will be receiving from each RRE, which is how the prior section was, per the authors' experience, typically interpreted.

Other Updates

Rounding out the Chapter III update, it is noted that CMS reworded Section 6.5.1.3 regarding “Joint settlements, judgments, awards, or other payments.” Of note, while CMS has made some wording changes, these updates do not alter CMS’s long-standing directives regarding an RRE’s reporting responsibilities in these situations. See the endnote to this sentence for a comparative outline of CMS’s new updates to this section versus the agency’s prior wording.^[7]

Chapter IV Updates

CMS states as follows in the Chapter IV Summary of Changes page: “The number of days required to generate a response file for claim files has been corrected from 48 to 33 (Chapter 7). Starting April 2026, new reason codes will be available to further improve granularity and clarity of updates to MSP and drug coverage records. The new codes have been added to the Change Reason Description table with an asterisk (*) (Table 7-4).”^[8]

The Chapter IV updates are summarized as follows:

Claim Input File - Processing Time

CMS has made a correction to the timeframe for Claim Input File processing from 48 to 33 days, within Section 7 of Chapter IV which, of note, is not a new change to the file processing timeframe. In this regard, per the authors’ best recollection, the change to 33 days was actually implemented by CMS in practice approximately 10 years ago, although CMS’s User Guide continued to reference a 48-day processing window. As such, through this new User Guide change CMS appears to be simply updating a long-outdated reference to the original file processing timeframe which had applied during the earlier stages of the Section 111 reporting process.

Unsolicited Response File (Additional Change Reason Codes)

A significantly more notable Chapter IV update relates to the Unsolicited Response File process and, more specifically, to the Change Reason Codes which CMS may return via that process. As a brief refresher, the Unsolicited Response File is a voluntary process via which an RRE may opt to receive a monthly file from CMS which provides notification of manual updates which have been applied by the BCRC to the Section 111 coverage records that the RRE has previously submitted to CMS.^[9]

In terms of placing CMS’s updates in context, it is noted that up until to this time, there have only been two potential Change Reason Codes which could be returned to an RRE via this process. First is the code “CT” which represents an update/change to the termination date on an RRE’s previously submitted ORM coverage record. Second is the “DO” code which represents the deletion of an RRE’s previously submitted ORM coverage record.^[10] In relation to these codes, the BCRC may manually apply an ORM Termination Date to an RRE’s Section 111 ORM coverage record in the event that they receive what they determine to be sufficient information warranting that update. Updates of this nature may be made based on information received from the Medicare beneficiary or their representative or may also be made based on a manual request received directly from the RRE that initially posted the coverage. Furthermore, the BCRC may delete an ORM coverage record if they receive manual notification, outside of the Section 111 process, directly from the RRE. Based on the authors’ direct experience and feedback received from the BCRC, the BCRC should only delete a coverage record based on information they receive directly from the RRE that submitted the data and not based on a request from the beneficiary or their representative.

Against this backdrop, CMS, as part of its new User Guide update, has now added two new additional Change Reason Codes to their Unsolicited Response File Chage Reason Description table (Table 7-4) which the agency has indicated will begin to be returned as of April 2026.^[11]

The first new code is “AO” for which the description of “Added occurrence (As of April 2026)” has been provided.^[12]The second new code is “SP” for which a description of “SP error correction (As of April 2026)” has been provided.^[13]Of note, as of this time, the only information CMS has provided about these two new Change Reason Codes are the aforementioned descriptions and text stating: “Note: Starting April 2026, new reason codes will be available to further improve granularity and clarity of updates to MSP and drug coverage records. The new codes have been added to Table 7-4 below, with an asterisk (*)” which simply mirrors the above noted language the agency included in their Chapter IV summary of updates.^[14]

From the authors’ perspective, these updates are both surprising and puzzling when considered in relation to the sole historical purpose of the Unsolicited Response File which has been to inform RREs when records which they had successfully submitted to CMS via the Section 111 process have been manually updated by the BCRC outside the Section 111 process. In this regard, CMS’s new codes would not appear to be in specific reference to updates to an RRE’s previous successfully submitted records which, up until this point, has been the focus of the Unsolicited Response File process.

More specifically, on this point, the “AO” code representing the addition of a new occurrence (in CMS speak “occurrence” would typically refer to a coverage record) obviously would not be an update to a previously submitted Section 111 record. At present, based on the minimal information CMS has provided, it is unclear how this would even work as this would seem to be outside the scope of the entire premise of the Unsolicited Response File. The addition of a new “occurrence”/coverage record would not be an update to a record which an RRE had previously submitted via Section 111. Rather, it would simply be a new non-Section 111 coverage record created within CMS’s system. The Unsolicited Response File process involves the return of a DCN (Document Control Number) value which the RRE would have included when submitting their prior electronic Section 111 report. If a new coverage record is being manually added by the BCRC, there would be no DCN value to return via the RRE’s file. Furthermore, it is unclear how CMS may even identify an appropriate RRE ID via which a record may be returned on an associated file unless the record is created based on the RRE’s direct request where the RRE is able to provide them with the appropriate associated RRE ID. From the authors’ perspective, this could get particularly confusing in scenarios involving RREs who have numerous separate and distinct RRE IDs which is a common scenario.

Regarding the “SP” Change Reason Code update, when an RRE receives an SP error via their Section 111 Claim Response File, that means that the associated coverage record, or coverage record update, was not accepted and not successfully applied within CMS’s system. Thus, again, this would seem to be a scenario where there had either been no coverage record successfully applied at all via Section 111 or where a coverage record update had failed to be successfully applied. Similar to the “AO” Change Reason Code, from the authors’ perspective, this “SP” code appears to be misapplied within the confines of the historical Unsolicited Response File process.

Keeping the above points in mind, it would appear reasonable from the authors’ perspective to assume that these updates will likely cause confusion and generate many questions from those Section 111 RREs who participate in this optional process. In this regard, it remains to be seen whether CMS may offer additional information or insight into the thought process involved here and how they anticipate this might work from more of a technical logistical perspective. While the intent of the Unsolicited Response File has been to provide RREs with greater insight into any updates applied to their Section 111 data and to help them understand precisely what updates had been applied, from the authors’ perspective, these new additions to the process would seem more likely to cause greater confusion rather than providing further insight and clarity.

Chapter V Updates

CMS states as follows in the Chapter V Summary page: “The definitions of field 43 of the Claim Input File Detail Record table and CW09 of the Claim Response File Error Code Resolution table have been expanded for clarification (Appendix A and Appendix G). To ensure consistency of data the Recovery Agent TIN field is required if agent name is submitted (Appendix B and Appendix G).”^[15]

The Chapter V updates are summarized as follows:

Professional Administrator (EIN)

The update to field 43 of the Claim Input File (Appendix A) as noted above refers to the description of the Professional Administrator EIN field which is one of CMS’s recently added WCMSA related data elements. CMS has added new text to the description field indicating that “Field may not be blank (all spaces). Must contain 9-digit numeric value. Fill with zeroes if unknown.”^[16]This replaces text which had previously simply indicated “If unknown, enter all 0s.”^[17]Overall, from the authors’ perspective, this is a minor bit of additional clarification and not actually anything new or terribly notable.

Recovery Agent TIN

Regarding the noted Recovery Agent TIN updates, CMS made a very minor update to the Description for field 24 (Recovery Agent TIN) within Appendix B (TIN Reference File Layout). Prior to the update, the Description column included text indicating, “As of October 6, 2025, required if Recovery Agent Mailing Name (Field 16) is submitted.”^[18]The only change applied here was the removal of the “As of October 6, 2025” reference as this change has since been implemented and the current text now reads: “Required if Recovery Agent Mailing Name (Field 16) is submitted.”^[19] Similarly, the TN41 error code has been updated within Appendix G. Prior to the change, the Error Code column had contained text indicating “(As of October 6, 2025)” and that text has also been removed as this change has now been implemented.^[20]

CW09 Error

The update to the CW09 error as part of the Claim Response File Error Code Resolution table (Appendix G) refers to the error which CMS will return when field 43 (Professional Administrator EIN) contains an invalid value. CMS has added the following text to the “Possible Cause” column: “Error will not cause record rejection, but the error code will continue to appear on the response file. Correct and resubmit on your next quarterly file submission.”^[21]In other words, this is what CMS will sometimes refer to as a “soft error” or “soft edit.” While CMS and the BCRC had previously provided similar feedback during past TPOC/WCMSA webinars and other informal communication prior to the current update, up until this point CMS had not specifically identified the CW09 as an error that “will not cause record rejection” within the NGHP User Guide. From the authors’ perspective, this is an important point of clarification, and it is helpful that CMS has documented this guidance.^[22]

CW08 Error

Another update which may be noteworthy, which CMS did not specifically highlight within their summary of changes at the beginning of Chapter V, is in relation to the CW08 error which is the error returned when field 42 (Case Control Number), also one of CMS’s new WCMSA related fields, is submitted with an invalid value.^[23]In this regard, CMS added the following language to the Possible Cause column of Appendix G: “The CCN/DOI combination does not match an existing WCMSA case.”^[24]This is something regarding which CMS had also previously provided informal feedback which CMS has now documented in its User Guide.

Questions?

Please do not hesitate to contact the authors if you have any questions or would like to learn more about how Verisk can help you with Section 111 reporting.

[1] CMS’s Section 111 NGHP User Guide (Version 8.2, October 6, 2025), Chapter III, Chapter 1: Summary of Version 8.2 Updates.

[2] CMS’s Section 111 NGHP User Guide (Version 8.2, October 6, 2025), Chapter III, Section 6.5.1.3.

[3] Id.

[4] Id.

[5] CMS’s Section 111 NGHP User Guide (Version 8.1, May 5, 2025), Chapter III, Section 6.5.1.3.

[6] CMS’s Section 111 NGHP User Guide (Version 8.2, October 6, 2025), Chapter III, Section 6.5.1.3.

[7] The new wording changes in Section 6.5.1.3 reads as follows: “Joint settlements, judgments, awards, or other payments – In a joint settlement situation, each RRE must report any responsibility it has for ongoing medicals on a policy-by-policy basis, without regard to the reporting or policy details of any other RRE. An RRE may need to submit multiple records for the same individual depending on the number of policies at issue for an RRE, and/or the type of insurance or workers’ compensation involved. Where there are multiple defendants and they each have separate settlements with the plaintiff, the applicable RRE reports that separate settlement amount. For a settlement, judgment, award, or other payment with joint and several liabilities, each RRE must report the total settlement, judgment, award, or other payment—not just its assigned or proportionate share.” CMS’s Section 111 NGHP User Guide (Version 8.2, October 6, 2025), Chapter III, Section 6.5.1.3.

For comparative purposes, the prior version of this section read as follows: “Joint settlements, judgments, awards, or other payments – Each RRE reports its ongoing medical responsibility and/or settlement/judgment/award/other payment responsibility without regard to ongoing medicals. Each RRE would also report any responsibility it has for ongoing medicals on a policy-by-policy basis. An RRE may need to submit multiple records for the same individual depending on the number of policies at issue for an RRE, and/or the type of insurance or workers’ compensation involved. Where there are multiple defendants and they each have separate settlements with the plaintiff, the applicable RRE reports that separate settlement amount. For a settlement, judgment, award, or other payment with joint and several liabilities, each RRE must report the total settlement, judgment, award, or other payment—not just its assigned or proportionate share.” CMS’s Section 111 NGHP User Guide (Version 8.1, May 5, 2025), Chapter III, Section 6.5.1.3.

[8] CMS’s Section 111 NGHP User Guide (Version 8.2, October 6, 2025), Chapter IV, Chapter 1: Summary of Version 8.2 Updates.

[9] CMS describes its Unsolicited Response File process as follows: “As of July 2023, RREs may opt in to receive a monthly NGHP Unsolicited Response File for NGHP ORM records. This file will alert them to records they submitted that were updated by an entity other than the RRE over the last month. The only entity other than the RRE who can update these records is a BCRC CSR/Analyst on behalf of the (verified) beneficiary, for an access to care issue. ORM is not terminated due to entitlement. Updates made by a BCRC Call Center representative based on a call from the RRE will also be noted in this file.” See, CMS’s Section 111 NGHP User Guide, (Version 8.2, October 6, 2025), Chapter IV, Section 7.5.

[10] CMS’s Section 111 NGHP User Guide (Version 8.2, October 6, 2025), Chapter IV, Table 7-4.

[11] Id.

[12] Id.

[13] Id.

[14] CMS’s Section 111 NGHP User Guide (Version 8.2, October 6, 2025), Chapter IV, Section 7.5 and Table 7-4.

[15] CMS’s Section 111 NGHP User Guide (Version 8.2, October 6, 2025), Chapter V, Chapter 1: Summary of Version 8.2 Updates.

[16] CMS’s Section 111 NGHP User Guide (Version 8.2, October 6, 2025), Chapter V, Appendix A.

[17] CMS’s Section 111 NGHP User Guide (Version 8.1, May 5, 2025), Chapter V, Appendix A.

[18] CMS’s Section 111 NGHP User Guide (Version 8.1, May 5, 2025), Chapter V, Appendix B.

[19] CMS’s Section 111 NGHP User Guide (Version 8.2, October 6, 2025), Chapter V, Appendix B.

[20] CMS’s Section 111 NGHP User Guide (Version 8.2, October 6, 2025), Chapter V, Appendix G.

[21]CMS’s Section 111 NGHP User Guide (Version 8.2, October 6, 2025), Chapter V, Appendix G.

[22] As part of CMS’s TPOC/WCMSA webinar held on April 16, 2024, CMS provided information regarding which error codes are considered “hard errors” versus “soft errors.” Specifically, CMS stated that all new WCMSA related error codes (CW01 – CW12) will be treated as “hard errors” resulting in a rejection of the coverage record submission with one exception. The one exception will be the error code correlating with the Professional Administrator EIN field (Field 43 – Error Code CW09) which will be treated as a “soft error.” In other words, receipt of a CW09 error will not result in an outright rejection of the RRE’s coverage report. However, all other WCMSA related error codes will result in a rejection of the submitted coverage report. This was particularly notable as CMS had not previously specified, via their prior webinar or their subsequent published documentation, whether the newly introduced WCMSA related error codes would be classified as “hard errors” vs “soft errors.”

[23] CMS’s Section 111 NGHP User Guide (Version 8.2, October 6, 2025), Chapter V, Appendix A and G.

[24] CMS’s Section 111 NGHP User Guide (Version 8.2, October 6, 2025), Chapter V, Appendix G.