CMS makes updates to Section 111 NGHP User (Version 7.0)

As reported in our recent article, in early January CMS released a new version of their Section 111 NGHP Section 111 User Guide (Version 7.0, January 9, 2023). One of the updates made in Version 7.0, as outlined in our prior article, relates to a new feature starting in July 2023 where 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. 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.

Waiting For Cms’s Section 111 Penalties “final Rule” – Status, Updates, And What’s Next

As discussed more fully in our article, this update indicates that CMS will permit other parties – other than the actual Section 111 RRE – to make updates to the Section 111 record submitted by the RRE. In the bigger picture, this update incorporates a trend 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 record. In our prior article, the authors discussed several concerns RREs will likely have with respect to CMS enabling other parties to amend their Section 111 filings. This includes certain parties, who were listed within the “Modifier Type Code and Modifier Name” table (Chapter IV, Table 7-3) who would seemingly have either no relation to NGHP claims or for whom update authority would seem highly questionable, such as, for example, employers/other plan sponsors, voluntary data sharing agreement entities or providers, etc.

On February 1, 2023 and February 3, 2023, CMS released February updates regarding this upcoming opt-in feature which, in general, corrects several data elements and associated codes which had apparently been inaccurate as contained in CMS’s initial Version 7.0 of its NGHP User Guide as first published on January 9, 2023.

The authors break down CMS’s new “updates” as released on February 1^st as follows:

CMS’s new updates re: upcoming Unsolicited Response File opt-in feature

The changes published by CMS through its February updates are outlined in Chapter IV and V of existing User Guide (Version 7.0). It is important to note that CMS has not issued a new User Guide in relation to these new updates; rather, they simply made updates to existing Version 7.0. Hence, it may not be immediately obvious to RREs, at least to those who do not subscribe to CMS’s Section 111 NGHP email notifications, that updates have even been published as the publication date of Version 7.0 remains as January 9, 2023, and there is no means of identifying the fact that Chapters IV and V have been replaced with updated versions without careful review of the “Summary of Version” sections within each chapter. Therefore, it is important that readers are very careful to re-download Chapters IV and V in order to ensure that they are working with the most current version. For the reader’s convenience, the following is the link to CMS’s NGHP User Guide page from which the updated Chapters IV and V may be downloaded here:

With the above noted, the pertinent updates made by CMS regarding the Unsolicited Response File opt-in feature are stated in the “Summary of Version” updates pages to Chapter IV and Chapter V as follows:

Chapter IV: “The modifier type codes CEM (Employer/Other Plan Sponsor Name), DSA (Name of the Voluntary Data Sharing Agreement (VDSA) entity), and PRV (From a Provider) will not be used in the NGHP Unsolicited Response File, and have been removed from the list (Table 7-3) [February 2, 2023].”

Chapter V: “The fields Relationship Code, Policy Holder’s First Name, Policy Holder’s Last Name, and Policy Holder’s SSN will not be used in the NGHP Unsolicited Response File layout. They have been replaced with filler in the layout description (Appendix F) [January 30, 2023].”

From a wider angle, the new updates made by CMS fall in the category of items related to the upcoming Unsolicited Response File changes the authors noted as puzzling in our prior article in terms of their applicability and correlation to NGHP claims and NGHP Section 111 reporting. In this regard, as noted above, CMS indicates that modifier type codes related to employers/other sponsors (“CEM”), voluntary data sharing agreement entities (“DSA”) and providers (“PRV”) have been removed from the table as they “will not be used.” Based on these updates, one might reasonably assume that this would indicate that CMS will not accept updates to NGHP Section 111 records from these types of entities. However, CMS does not specifically state this and, as such, this may be an item for further clarification by CMS. Assuming this is indeed CMS’s intention, this change may alleviate concerns that some RREs may have had about these types of entities being allowed to update the coverage records they have submitted via the Section 111 process.

In addition, as discussed in our prior article, there were some data elements which had previously been included within the new Unsolicited Response File Layout (Chapter V, Appendix F) which also do not seem applicable to NGHP coverage scenarios. For example, the “Relationship Code” (previously field 20) which applies specifically to GHP coverage, as well as the “Policy Holder’s SSN” (previously field 23) which is not something collected by CMS in relation to NGHP coverage. While the Section 111 NGHP Claim Input File does allow an RRE to report the “Policy Holder Last Name” and “Policy Holder First Name” those fields are optional and not required. As part of its February updates, CMS has now removed the “Relationship Code” as well as all three-policy holder related fields which include “Policy Holder’s First Name,” “Policy Holder’s Last Name,” and “Policy Holder’s SSN.” These four data elements were previously defined as fields 20 through 23, respectively. Now, within the updated file layout, field 20 (formerly Relationship Code) is now defined as “filler” while fields 21 through 23 (former policy holder related fields) have been entirely removed. The displacement value (position of the data element within the flat file layout) provided for the new field 20 now encompasses that of the old field 20 in combination with that of the old fields 21 through 23. Field numbers for attorney specific information, which formerly began in field 24, have been adjusted and now begin with field 21 after the removal of the policy holder specific data elements. That said, as the current displacement/spacing of filler found in the new field 20 has been adjusted to encompass the prior fields 21 through 23, the displacement/position of the attorney specific and subsequent fields has not changed within the file format despite the relabeling of associated field numbers.

Other considerations

While the updates issued by CMS as part of their February updates may provide better guidance on certain items regarding the upcoming Unsolicited Response File opt-in option, from the authors’ perspectives, there remain several other questions regarding which additional clarification would likely be welcomed by most RREs.

For example, there remain questions regarding the exact data elements CMS will allow a non-RRE party to change. Based on observations of recent trends, and given the information published regarding the new Unsolicited Response File process, it appears that CMS will terminate ORM and may even delete Section 111 coverage records altogether per information received from these non-RRE parties. However, other types of updates which CMS may allow are presently less clear. For example, there are questions regarding whether CMS will allow ICD codes to be updated by a non-RRE party. If so, how would those changes be relayed to the RRE as, currently, there are no fields within the Unsolicited Response File Layout pertaining to ICD codes.

As for other examples, it is unclear what CMS might mean when indicating an “Insurance Information Change” has occurred as reflected via a Change Reason Code value of “II” (See Chapter IV, Table 7-4 “Change Reason Description”). In relation to this, is CMS contemplating allowing changes to the insurer information to something other than that of the Section 111 RRE that initially reported the coverage? In addition, it is unclear what CMS may mean with respect to the “UK” (Unknown) Change Reason Code and what could be potentially encompassed as part of this type of update.

Also, given that CMS’s upcoming process is “optional,” what responsibility might an RRE have to correct erroneous updates that CMS may apply to their Section 111 records? On this point, as noted in the authors’ prior article, CMS’s upcoming change will essentially allow the Section 111 record to be changed by parties who will typically lack experience with the requirements related to Section 111 and the underlying law or other authority related to the claim. As such, allowing the Section 111 record to be changed by parties lacking this critical experience will very likely result in changes to the RRE’s filed Section 111 record based on inaccurate information. This reality in turn raises concerns from the Section 111 penalties perspective. Specifically, as indicated by the authors in their prior article, questions are raised regarding whether the larger policy of allowing other parties to update a Section 111 record makes sense – especially since the RRE remains ultimately responsible for the accuracy of Section 111 reporting and is the party subject to Section 111 civil money penalties.^[1]In this regard, it would not be surprising if RREs look for CMS to reconsider this change, or at least provide additional clarification.

Questions?

Verisk will continue monitor developments on this front and provide updates as warranted. Of course, please do not hesitate to contact the authors with questions.