CMS’s Section 111 NGHP Unsolicited Response File “opt-in” process

By Mark Popolizio, J.D., Jeremy Farquhar

June 27, 2023 / 22 min read

As many may recall, on May 16, 2023, the authors released their initial “Question & Answer” article regarding the Centers for Medicare and Medicaid Services (CMS’s) forthcoming Section 111 Non-Group Health Plan (NGHP) Unsolicited Response File “opt-in” feature which starts July 2023 (CMS’s materials do not specify an exact date, though it would appear reasonable to assume the start date is July 1^st). Our initial “Q&A” article was based on the information released by CMS up until that point and highlighted the many questions and unknown items as of that time.

Fast forward to early June. At that time, CMS then issued a new Section 111 NGHP User Guide (Version 7.2, June 5, 2023) and held a webinar on June 6^th through which the agency discussed its upcoming Section 111 NGHP Unsolicited Response File “opt-in” feature in more detail. As part of these releases, CMS provided a significant amount of new information regarding its forthcoming process. This information assisted in answering some of the outstanding questions and helped fill-in the blanks on some of the unknown items outlined in our May article.

understanding cms

Thus, given these new developments, the authors have now (i) updated their “Q&A” style overview of CMS’s upcoming process and (ii) prepared a supplementary “Nutshell Summary” resource presented as follows:

1. What is CMS’s Section 111 NGHP Unsolicited Response File “opt-in” feature?

CMS describes this upcoming process as follows: “As of July 2023, the following change will be made: To inform RREs when another source has updated their submitted records, RREs may now opt in via the Section 111 Coordination of Benefits Secure Website (COBSW) application to receive a monthly NGHP Unsolicited Response File. This will provide key information about updates to ORM records originally submitted in the last 12 months and allow RREs to either update their own internal data or contact the BCRC for a correction.”^[1]

2. Is the Unsolicited Response File process mandatory?

No. CMS, as part of its recent webinar, stated that the Unsolicited Response File “opt-in” feature is voluntary, and that the RRE will not be considered out of compliance if they do not opt into the new process. However, while the process is optional, CMS urged RREs to opt in and participate.

3. Which NGHP RREs can “opt-in” to this process?

CMS on its webinar advised that this process is only available for file submitters – and is not being offered to Direct Data Entry (DDE) reporters. CMS has also advised that the opt-in process must be performed individually for each participating RRE ID – it will not allow a large group of RRE IDs to opt into the process en masse. In addition, CMS advised that there is a sample Unsolicited Response File which can be provided to an RRE for testing purposes. CMS directed interested RREs to contact their assigned EDI Representative to request a copy of the file.

4. How can a NGHP RRE “opt-in” to this process?

A part of its recent webinar, CMS outlined the following steps for RREs to opt into this new process:

New RRE ID registrations - For RREs registering for a new RRE ID, the ability to opt in will be added to the Account Setup portion of the registration process via CMS’s Section 111 COBSW. When completing the Account Setup process for a new RRE ID, beginning in July, registrants will see a newly added question asking, “Would you like to receive Unsolicited Alerts?” followed by the statement, “Check here to receive Unsolicited Alerts” coupled with a radio button which may be selected by the registrant to opt in.

Existing RRE accounts -- CMS explained that RREs with existing accounts also can opt in via the Section 111 COBSW. In these instances, also beginning in July, RREs will have the ability to opt into the process via the RRE ID Profile Information screen where they will see a new radio button, similar to that outlined above, which may be selected to participate in the new process.

Further, CMS advised that the RRE’s Account Manager (AM) is the party who should opt an RRE into the Unsolicited Response File process. CMS also noted that there would be a new version of CMS’s Section 111 COBSW User Guide, posted within the Reference Materials file menu of the Section 111 COBSW, which will contain more explicit details regarding the opt in process.

5. Who can update the Section 111 record?

Per CMS, the only non-RRE parties who can update the Section 111 ORM record, other than the RRE, is the associated beneficiary or their authorized representative.^[2]

6. How will CMS receive the information?

CMS explained in its webinar that the agency will use the BCRC Call Center to accept updates to the Section 111 ORM records as part of this process. In addition, CMS emphasized that it will only accept updates from the beneficiary associated with the ORM coverage record in question, that beneficiary’s authorized representative, or the RRE responsible for reporting the ORM coverage record via the Section 111 process. Further, CMS explained “access to care” related issues are the reason why the agency presently accepts (and will continue to accept) updates from the beneficiary or their authorized representative. CMS also mentioned that RREs may occasionally contact the BCRC Call Center to request off-cycle updates between their Section 111 file submissions and that these updates will also be reflected within the new Unsolicited Response File.

7. What information will CMS accept as part of this process?

As part of its webinar, CMS explained that the ORM Termination Date is the only piece of information that the BCRC Call Center will update based on a request from the beneficiary or their authorized representative, if deemed appropriate by the BCRC Call Center representative. It was noted that, for any request to update additional data elements, the beneficiary or their authorized representative would be referred to the Section 111 RRE to request that the RRE apply those updates if deemed appropriate.

As part of this process, CMS explained that the BCRC Call Center representative will ask the caller a series of questions to determine if the criteria to apply such an update has been appropriately met. These questions will include the following: Is the beneficiary still being treated for their injuries? Is the coverage/case still ongoing? Has the coverage been exhausted? Does the beneficiary have a release from their treating physician? Based on the answers to these questions, the BCRC Call Center representative, if deemed appropriate, will apply an ORM Termination Date to the Section 111 ORM coverage record.

8. Can the beneficiary, or their authorized representative, delete the ORM coverage record?

No. As part of its webinar, CMS clarified that ORM coverage records are only deleted per direct request from the RRE. ORM coverage records cannot be deleted per request from a beneficiary or their representative. If the participating RRE contacts the BCRC Call Center and requests a deletion outside the standard Section 111 process, the Unsolicited Response File will reflect a record indicating that deletion.

9. How will CMS return the Unsolicited Response File?

CMS advised on its webinar that the Unsolicited Response File will be made available on the 2^nd Sunday of each calendar month and that files will be returned via the same transmission method already utilized for each RRE’s other response files. In terms of what information will be returned, CMS outlined all the specific data elements slated to be returned as part of the Unsolicited Response File layout found within Chapter V of the newly published Version 7.2 of the Section 111 NGHP User Guide. See, CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter V, Appendix F. Click here to view Appendix F.

10. What if the Unsolicited Response File contains inaccurate information?

On the webinar, CMS stated that RREs, upon receipt of the Unsolicited Response File, should review the file to verify the accuracy of the updated information and, if the update is inaccurate, the RRE should submit a correction on their next Section 111 file.

11. What if the Unsolicited Response File contains erroneous ORM termination dates?

On the webinar, CMS received numerous questions about expectations from RREs when erroneous ORM termination dates are identified via the Unsolicited Response File and whether an update should be submitted via Section 111 to correct the erroneous update. Further, CMS was asked if, even in scenarios where the prior Section 111 report was correct, if RREs were expected to send an update even though their reported data had not changed, and if a Section 111 update would be required if the RRE contacted the BCRC Call Center to request the correction of an erroneous ORM termination date. In response to these questions, CMS indicated that an RRE would be expected to submit an update via the Section 111 process in all the above scenarios. In addition, CMS advised that there is not a specific mechanism to prevent flip-flopping of data in scenarios where an ORM termination date is applied erroneously based on a beneficiary/beneficiary representative call where the RRE subsequently corrects the erroneous update. In this situation, BCRC protocol instructs their Call Center Representatives to escalate to a supervisor if such scenarios are noted, but there is nothing to technically prevent flip-flopping of data and the repeated application of the erroneous ORM termination date.

12. Will this process impact CMS’s conditional payment recovery process?

CMS stated on its webinar that updates made to the Section 111 ORM coverage records as part of the Unsolicited Response File process would not directly impact conditional payment recovery cases or processes. On this point, CMS stated that only the ORM coverage record which would affect access to care and coordination of benefits would be impacted. In addition, CMS advised that the Unsolicited Response File will not replace the letters that the BCRC currently mails out to RREs when an ORM Termination Date has been reported by a beneficiary or their authorized representative. This longstanding practice will continue.

13. What information will CMS provide within the Unsolicited Response File record layout?

Information regarding the Unsolicited Response File record layout can be found at CMS’s Section 111 NGHP User Guide, Version 7.2, Chapter V, Appendix F. On this item, it is noted that CMS recently made some significant updates to the record layout as part of the new Section 111 NGHP User Guide (Version 7.2, June 5, 2023).

For example, as part of CMS’s recent User Guide updates to Chapter V, Appendix F, the agency removed numerous fields which had been included in earlier published versions. While many fields have been removed, no new fields have been added and all current fields maintain their same prior placement/position within the file. Filler spaces have simply been added to replace the prior data elements which have now been removed and many field numbers have been adjusted accordingly.

Data elements which have been removed from the revised Version 7.2 layout include: (i) Insurer Name and Address Fields (formerly field numbers 11 through 16); (ii) Attorney Name and Address Fields (formerly field numbers 12 through 26); and (iii) Group Insurance Policy/DOL (formerly field 27).^[3]These recently removed data elements are in addition to CMS’s removal of Relationship Code, Policy Holder’s First Name, Policy Holder’s Last Name, and Policy Holder’s SSN (all fields that are not relevant to NGHP Section 111 reporting) via updates to NGHP User Guide Version 7.0 in early February.^[4] Remaining data elements include items such as beneficiary personal identifying information, the DCN value linked to the RRE’s most recent Section 111 report, MSP Effective/Termination Dates, as well as Modifier Type and Change Reason Codes. For a complete list of the remaining data elements, please refer to CMS’s NGHP User Guide, Version 7.2, Chapter V, Appendix F.^[5]

14. What information will CMS relay via the Modifier Type Code and Change Reason Code fields?

In addition to the removal of the data elements within the Unsolicited Response File record layout as discussed above, NGHP User Guide (Version 7.2) also made significant revisions to the potential Modifier Type Code and Change Reason Code values which may be returned via the corresponding fields within the Unsolicited Response File record layout. For a current list of valid Modifier Type Code and Change Reason Code values, please see NGHP User Guide, Version 7.2, Chapter IV, Section 7.5, Tables 7-3 and 7-4 respectively.^[6]

For the reader’s convenience, the authors provide a general overview regarding key aspects related to the Modifier Type and Change Reason codes as follows:

Response records will contain information about the source of, and reason for, the update – Each NGHP Unsolicited Response File record will return a “Modifier Type Code” value which will indicate the type of entity from which CMS received the information utilized to update the RRE’s ORM coverage record as well as a “Modifier Name” which provides the entity name or description.^[7] In addition, each NGHP Unsolicited Response File record will return a “Change Reason Code” which will provide information about the reason for the update and/or the type of update applied.^[8]

Certain Modifier Type Codes have been removed – With Version 7.2 of their NGHP User Guide CMS recently removed the following Modifier Type Codes from this process: BCR (BCRC Contractor), ECR (Other Medicare Contractor), RRE (RRE other than the participating recipient/original reporter) and WCS (Workers’ Compensation Review Contractor) have all been removed from Table 7-3.^[9]These are in addition to the following which were also removed via prior revisions: CEM (Employer/Other Plan Sponsor Name); DSA (Name of the Voluntary Data Sharing Agreement (VDSA) entity); and PRV (From a Provider).^[10] Accordingly, CMS states that these codes will not be used in the NGHP Unsolicited Response File.^[11]

Remaining Modifier Type Codes (only two codes remain) – Subsequent to the removal of the aforementioned, only the two following Modifier Type Codes remain: (1) the “CBN” code which represents information received from the associated Medicare beneficiary and (2) the “CIN” code which relates to information received from the associated RRE outside of the standard Section 111 reporting process.^[12]

Certain Change Reason Codes have been removed - In addition, Change Reason Codes, utilized by CMS to indicate the type of update applied, of II (Insurance Information Change), UK (Unknown) and Blank (System-Generated, Reason Unknown) have been removed from Table 7-4.^[13]

Remaining Change Reason Codes (only two codes remain) - The two remaining Change Reason Codes are as follows: (1) the CT code which represents a change to the ORM Termination Date and (2) the DO code which indicates that the ORM record has been deleted.^[14]

15. What file naming conventions will CMS utilize for the new Unsolicited Response Files?

As a part of their new Version 7.2 User Guide updates, CMS provided updated information regarding file name formats. That information has been added to Chapter IV, Section 10.2 for those RREs utilizing a Connect:Direct file transmission method.^[15] That file naming convention has been provided as follows:

P#EFT.ON.Rxxxxxxx.UNS.Dyymmdd.Thhmmsst
- Where:
  - P#/T# = Production or test
  - Rxxxxxxx = RRE ID padded with zeros (i.e., R0080043)
  - Thhmmsst = Current date and time^[16]

It may be worth noting that CMS only published the file naming conventions for Connect: Direct transmission methods via their Version 7.2 User Guide updates. SFTP and HTTPS file naming conventions were not published. However, CMS did provide information regarding SFTP file naming conventions during its recent webinar. Specifically, on the webinar CMS advised that the file name will follow the same format as other SFTP response files except “UNS” will replace the several characters which denote the specific file type (PCOB.BA.MR.NGHPUNS.RESP.Dccyymmdd.Thhmm####.TXT). NOTE: the authors have bolded the updated portion of the file name for the reader’s convenience. While HTTPS file naming conventions were not specifically noted, for all other response file types those HTTPS naming conventions mirror those used for SFTP and one might reasonably assume the same would apply here.

16. How could this process impact Section 111 civil money penalties (CMPs)?

CMS has not provided any information regarding whether, if at all, the updates being accepted from the beneficiary or their authorized representative, subsequently relayed via the Unsolicited Response, could potentially impact Section 111 CMPs.^[17] On this point, given that CMS’s upcoming process is “optional,” a key question is what responsibility may an RRE have to correct erroneous updates that CMS may apply to their Section 111 ORM records? This is a particularly interesting question given that CMS will essentially allow the Section 111 ORM records to be changed by parties who typically lack experience with the requirements related to Section 111, not to mention the underlying law or other authority related to the claim. As such, allowing the Section 111 ORM records to be changed by parties lacking this critical experience will very likely result in changes to the RRE’s filed Section 111 records based on inaccurate information.

Given this reality, legitimate concerns surface regarding Section 111 CMPs. Specifically, a key point is whether, from a larger policy perspective, allowing parties to update a Section 111 ORM record, other than the actual RRE, makes sense – especially since the RRE remains ultimately responsible for the accuracy of Section 111 reporting and, at the end of the day, is the party subject to Section 111 civil money penalties.^[18] As such, it will be interesting to see if CMS modifies its current CMPs proposals to account for this fact as it moves toward releasing its “final” CMPs rule.

17. Where can I find additional CMS information about this new process?

Information regarding this process can be found in CMS’s current User Guide: Section 111 NGHP User Guide (Version 7.2, June 5, 2023). See generally, Chapter IV, Section 7.5 and Chapter V, Appendix F.

Nutshell Summary – additional resource

As a secondary resource, the authors have prepared a Nutshell Summary which some may find helpful as a supplementary resource to be used in conjunction with this article and CMS’s published resources on this topic.

Special note for Verisk Section 111 reporting customers

Please note that for customers reporting through one of Verisk's S.111 reporting solutions, you will be able to view and/or intake the new file and trigger a claim to be resubmitted for correction, even if no updates have been made by the RRE. Further specifics regarding Verisk’s updated processes will follow for our customers. If you are not a current Section 111 reporting customer but would like more information about our Section 111 reporting solution, MSP Navigator, please do not hesitate to contact us at support@mspnavigator.com

Questions?

The authors will continue to monitor developments on this front and provide updates as warranted. In the interim, do not hesitate to contact us if you have any questions.

[1] See, CMS’s Section 111 NGHP User Guide, (Version 7.2, June 5, 2023), Chapter IV, Section 7.5 and CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter V, Appendix N.

In the big picture, this new “opt-in” feature incorporates a trend (perhaps troubling trend in the eyes of many RREs) that has been occurring over the past several years where CMS has been allowing another party – other than the actual RRE – to make changes to the Section 111 ORM records. In this regard, this trend has deviated from CMS’s historical practices. On this point, historically, from the authors’ experience, at the beginning of the Section 111 reporting process, CMS had instructed its contractors not to apply updates to Section 111 ORM records based on information received from sources other than the RRE. In those situations, CMS would typically direct the individual/entity providing the contradictory information back to the RRE to discuss any appropriate corrections to the Section 111 ORM record as submitted by the RRE. In situations involving a request for ORM termination, CMS would also typically send a letter to the RRE informing them of the receipt of that contradictory information. The RRE would be instructed that they could submit an update, if appropriate, via the Section 111 process or that they could reach out to the BCRC to request and/or provide additional clarifying details. In those scenarios, if the RRE did not reach out directly or submit an update via the Section 111 process, the Section 111 record would remain as previously reported by the RRE. However, from the authors’ experiences, CMS’s approach as outlined above, has started to change over the past few years in that it has become more common for CMS to permit the BCRC to allow and apply updates to the Section 111 ORM record based on information received by a party other than the RRE. Most of time, it is the beneficiary who provides information leading to a change in the Section 111 ORM record. In these situations, CMS, unlike prior practice, makes the change without notifying the RRE. One partial exception to this regards ORM termination. In this scenario, the authors find that CMS continues to send letters to the RRE. However, contrary to prior practice, CMS has typically already applied the change to the RRE’s Section 111 ORM record. Thus, RREs may need to follow up with the BCRC to ensure that their Section 111 ORM record was not updated inappropriately.

[2] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter IV, Section 7.5.

[3] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter V, Appendix F.

[4] CMS’s Section 111 NGHP User Guide (Version 7.0, January 9, 2023), Chapter IV, Section 1 (“Summary of Version 7.0 Updates” page) and CMS’s Section 111 NGHP User Guide (Version 7.0, January 9, 2023) Chapter IV, Section 7.5, Table 7-3. Of note, CMS published three separate iterations of NGHP User Guide Version 7.0 (rather than issuing new Version updates), all of which contained separate and distinct updates. In this regard, the documents all reflect the original January 9, 2023, publication date, but revised iterations were subsequently posted on February 1, 2023 and February 3, 2023. With all this noted, the specific updates highlighted were only noted within the iteration posted on February 1, 2023.

On another note, from the authors’ perspective, while removal of the insurer and attorney related data elements makes sense in the greater context of all the changes outlined above, the removal of the field formerly labeled “Group Insurance Policy/DOL” is both puzzling and problematic. From the authors’ view, this is because the Date of Loss (DOL) is a pertinent piece of information which many RREs may rely upon to help identify the claim in question. While the inclusion of “Group Insurance Policy” within the prior field name was confusing and would not have been applicable for an NGHP coverage, the DOL would have been applicable, and one could have reasonably assumed that CMS had intended to return that value in this field. A correction to the field name, as opposed to a removal of the field in its entirety, may have been more appropriate and the authors are hopeful that CMS might reconsider this specific change and re-add this field to return the DOL.

[5] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter V, Appendix F.

[6] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter IV, Chapter 7, Section 7.5, Table 7-3 and 7-4.

[7] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter IV, Chapter 7, Section 7.5, Table 7-3 and CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter V, Appendix F.

[8] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter IV, Chapter 7, Section 7.5, Table 7-4 and CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter V, Appendix F.

[9] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter IV, Section 7.5, Table 7-3.

[10] CMS’s Section 111 NGHP User Guide (Version 7.0, January 9, 2023), Chapter IV, Section 1 (“Summary of Version 7.0 Updates” page) and CMS’s Section 111 NGHP User Guide (Version 7.0, January 9, 2023) Chapter IV, Section 7.5, Table 7-3. As also referenced in n.4 above, CMS published three separate iterations of NGHP User Guide Version 7.0 (rather than issuing new Version updates), all of which contained separate and distinct updates. In this regard, the documents all reflect the original January 9, 2023, publication date, but revised iterations were subsequently posted on February 1, 2023 and February 3, 2023. With all this noted, the specific updates highlighted were only noted within the iteration posted on February 1, 2023.

[11] CMS’s Section 111 NGHP User Guide (Version 7.0, January 9, 2023), Chapter IV, Section 1 (“Summary of Version 7.0 Updates” page) and CMS’s Section 111 NGHP User Guide (Version 7.0, January 9, 2023) Chapter IV, Section 7.5, Table 7-3. As also referenced in n.4 above, CMS published three separate iterations of NGHP User Guide Version 7.0, all of which contained separate and distinct updates. The documents all reflect the original January 9, 2023 publication date but revised iterations were subsequently posted on February 1, 2023 and February 3, 2023. The specific updates highlighted here were only noted within the iteration posted on February 1, 2023.

[12] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter IV, Section 7.5, Table 7-3.

[13] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter IV, Section 7.5, Table 7-4.

[14] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter IV, Section 7.5, Table 7-4.

[15] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter IV, Section 10.2.

[16] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter IV, Section 10.2.

[17] For information on CMS’s Section 111 CMPs, see our recent articles:

CMS pushes back the timeline to release its Section 111 penalties “final rule” for one-year (until February 18, 2024)

Section 111 penalties level-set: FAQs, updates, and what’s next

[18] See e.g., 42 U.S.C. 1395y(b)(8) and Section 111 NGHP User Guide (Version 7.1, April 24, 2023), Chapter III, Chapter 6, Section 6.2 and Section 111 NGHP User Guide (Version 7.1, April 24, 2023), Chapter V, Appendix H (”MMSEA Statutory Language.