CMS holds webinar to discuss Section 111 Non-Group Health Plan (NGHP)

By Jeremy Farquhar, Mark Popolizio, J.D.

June 7, 2023 / 11 min read

On June 6^th, the Centers for Medicare and Medicaid Services (CMS) held a webinar where the agency discussed its upcoming Section 111 Non-Group Health Plan (NGHP) Unsolicited Response File “opt-in” feature (starts July 2023), along with several other Section 111 reporting issues.

As part of this hour-long session, CMS first discussed various updates regarding its upcoming Unsolicited Response File process before turning to other recent updates. A good portion of CMS’s presentation mirrored recent updates the agency announced a few days before the webinar as part of its new Section 111 NGHP User Guide (Version 7.2, June 5, 2023). After completing its initial discussion, the agency opened the lines for a “question/answer” session.

cms blog

The below provides a general summary of key points discussed by CMS on this webinar, as part of its presentation and in response to attendee questions, as follows:

Section 111 NGHP Unsolicited Response File “opt-in” (starts July 2023)

By way of brief background, starting July 2023, RREs will be able to “opt-in,” via the Section 111 Coordination of Benefits Secure Website (COBSW) application, to receive a monthly NGHP Unsolicited Response File.^[1] This will provide key information about updates to ORM records, originally submitted by the participating recipient RRE, within the last 12 months, and allow RREs to either update their own internal data or contact the BCRC for a correction.^[2] CMS held this webinar to provide information regarding this upcoming process. Overall, CMS’s discussion regarding this upcoming process closely charted the updates the agency recently posted as part of Section 111 NGHP User Guide (Version 7.2, June 5, 2023). Click here for our article on User Guide (Version 7.2).

The following are key points discussed by CMS regarding this matter:

Unsolicited Response process – objectives

On this topic, CMS simply indicated that the intent was to improve the accuracy of the Section 111 data and, while the process is optional, they did urge RREs to opt in and participate. However, CMS stated that this remains voluntary, and an RRE will not be considered out of compliance if they do not opt into the new Unsolicited Response File process.

Process only available for file submitters

CMS stated that the Unsolicited Response File is only be available for file submitters. It is not being offered to Direct Data Entry (DDE) reporters. CMS also advised that the opt in process must be performed individually for each participating RRE ID – CMS will not permit a large group of RRE IDs to opt into the process en masse. Also, 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.

How RREs can opt into this new process

CMS outlined the steps for RREs to opt into this new process as follows:

New RRE ID registrations

For RREs registering for a new RRE ID, the ability to opt in has been 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 in order 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, 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. It was also noted that this is something that would need to be facilitated via the RRE’s Account Manager.

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, which will contain more explicit details regarding the opt in process.

Process specifics: BCRC call center, who can make changes, and RRE “off-cycle” updates

CMS advised that the BCRC Call Center will be used 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 in order 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.

Only an ORM termination date will be accepted – how the process will work

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 in order 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.

CMS indicated that, upon receipt of the Unsolicited Response File, RREs should verify the updated information and, if the update is determined to be inaccurate, the RRE should submit a correction on their next subsequent Section 111 file. Another important point which CMS highlighted here is that any updates made to the Section 111 ORM coverage records would not directly impact conditional payment recovery cases or processes. Only the ORM coverage record which would affect access to care and coordination of benefits would be impacted.

On a related point, 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.

Only the RRE can delete the ORM coverage record

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.

Erroneous ORM termination dates

CMS received numerous questions about expectations from RREs when erroneous ORM termination dates are identified via the Unsolicited Response File. Attendees asked questions about whether an update must be submitted via Section 111 to correct the erroneous update. It 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. It was also asked 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 of the aforementioned 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.

File delivery and information to be returned

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

Naming Convention

CMS advised that the file name will be the same 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 highlighted in bold the updated portion of the file name for the reader’s convenience.

Other Section 111 Updates Addressed by CMS

CMS also addressed several other Section 111 topics including:

'NOINJ’ code (liability cases) now optional

As outlined in its recent User Guide (Version 7.2 updates), CMS explained that reporting of the ‘NOINJ’ code for certain liability scenarios meeting the criteria outlined in Chapter IV, Section 6.2.5.2 of its User Guide is now optional. While ‘NOINJ’ reporting is no longer required, CMS stated that RREs may still voluntarily report these scenarios using the ‘NOINJ’ code if they so desire and if RREs opt to report this code they will need to continue to follow CMS’s explicit instructions which they outline in Chapter IV, Section 6.2.5.2. Further, CMS was careful to indicate that, while these ‘NOINJ’ coverage reports are no longer required, if RREs had successfully reported these types of coverages in the past, they should not attempt to circle back and delete those previously reported coverages.

ORM reporting trigger updates

CMS also referenced its recent updates made regarding the criteria for ORM assumption as outlined in Chapter III, Section 6.3 of its new User Guide.

On this point, CMS’s power point referenced that the trigger for reporting ORM is the assumption of ORM by the RRE, which is when the RRE has made a determination to assume responsibility for ORM and when the beneficiary receives medical treatment related to the injury or illness; and that Medical payments do not actually have to be paid, nor does a claim need to be submitted, for ORM reporting to be required. The effective date for ORM assumption is the DOI, regardless of when the first medical treatment was received by the beneficiary or when ORM assumption is reported. See the authors’ recent article on CMS’s User Guide (Version 7.2) for further information.

Regarding this update, CMS was asked if an ORM coverage was previously successfully reported, where the beneficiary never received treatment, whether the RRE could now update ORM to “No” (i.e. delete the previously reported ORM coverage). In response, CMS indicated that in this situation it is not permissible for RREs to delete prior successful ORM reports, if an RRE would have had responsibility for payment should treatment be received, solely because treatment was not received.

Treating physician statement and the ORM termination “date”

CMS referenced the updates made in User Guide (Version 7.2) regarding the “date” to be used by the RRE when terminating ORM based on a statement from the claimant’s treating physician meeting CMS’s requirements.

In this scenario, as reflected in CMS’s power point and in Chapter III, Section 6.3.2, CMS’s guidance is as follows:

Where the statement specifies a date as to when no further treatment was required, that date should be the reported ORM termination date.

Where the statement does not specify a date when no further treatment was required, the date of the statement should be the reported ORM termination date.

Where the statement has not specified a date when no further treatment was required, nor is the statement dated, the last date of related treatment should be used as the ORM termination date.

See the author’s recent article on CMS’s User Guide (Version 7.2) for further information.

Special note for Verisk Section 111 reporting customers (NGHP Unsolicited Response File)

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. 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?

Please do not hesitate to contact the authors if you have any questions.

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

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