The Centers for Medicare and Medicaid Services (CMS) has released an updated Section 111 NGHP User Guide (Version 7.2, June 5, 2023) regarding Section 111 reporting related to non-group health plans (liability, no-fault and workers’ compensation).
As usual, CMS lists the new updates in the beginning of each User Guide chapter in a “Summary” page. Reviewing these pages indicates that updates were made to Chapter III (Policy Guidance) and Chapter IV (Technical Information).
The following provides an overview of the changes made in NGHP User Guide (Version 7.2):
Summary
Overall, CMS has made several updates as part of Section 111 NGHP User Guide (Version 7.2). The authors outline these updates in greater depth in each of the sections below.
However, given the detailed nature of CMS’s changes, the authors first provide the reader with a quick general overview of the key changes as the reader prepares to review the updates in more detail below as follows:
- Section 111 Unsolicited Response File – several updates are made, including clarifications regarding “who” may update the ORM record; removal of certain modifier type codes (only two modifier type codes remain); removal of certain change reason codes (only two change reason codes remain); removal of numerous fields within the file layout; and file name formats have been added.
- 'NOINJ' Code (Liability Claims) – reporting of the ‘NOINJ’ code now optional.
- ORM termination – new guidance re: physician statement and the ORM termination “date.”
- ORM trigger guidance clarification – CMS provides updates regarding ORM assumption.
- HEW software updates – clarification regarding end of line markers indicating that the HEW software utilizes a line feed (LF) as opposed to a carriage return (CRLF) to separate records.
The below sections now examine each of these updates in greater detail as follows:
Section 111 NGHP Unsolicited Response File “opt-in” feature (starts July 2023)
In the Summary update page to Chapter IV, CMS states: “[t]he NGHP Unsolicited Response File format has been simplified, and filename formats have been added (Section 7.5 and Chapter 10).”[1] In addition, the Summary update page to Chapter V states: “[t]he NGHP Unsolicited Response File layout has been simplified (Appendix F).”[2]
As a reminder, 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.[3] 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.[4]
CMS has made several updates to its upcoming Section 111 NGHP Unsolicited Response File “opt-in” feature which the authors break down as follows:
Clarification as to “who” may update the ORM record
The first item of note involves some additional language which CMS has added to the first paragraph of Chapter IV, Section 7.5 which reads as follows:
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.[5]
This new language, in addition to corresponding revisions to Tables 7-3 and 7-4 outlined below, is very helpful in clarifying both the types of updates CMS will accept from parties other than the RRE, and from whom exactly those updates may be accepted. These were items of concern which the authors had referenced as part of their prior articles on this topic. These updates will likely be viewed as answering those questions and may also alleviate certain elements of concern for many RREs.
Removed Modifier Type Codes
Modifier Type Codes, utilized by CMS to indicate the type of entity that requested the update, of 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.[6]
Remaining Modifier Type Codes (only two codes remain)
As part of the updates, only two Modifier Type Codes remain at present as follows: (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.[7] In addition, field number references, within the header row of Table 7-3, have also been updated to coincide with the newly revised Unsolicited Response File Layout published within Chapter V, Appendix F.[8]
Removed Change Reason Codes
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.[9]
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.[10] The field number reference within the Table 7-4 title has also been updated to coincide with the newly revised Unsolicited Response File Layout published within Chapter V, Appendix F.[11]
Unsolicited Response File Layout Changes
The Unsolicited Response File Layout (Chapter V, Appendix F) has also seen significant revisions with numerous prior fields having been removed. An important note here is that, while many fields have now been removed from the layout, there have been no new fields added and all current fields maintain their same prior placement within the file. In other words, none of the remaining fields have changed 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 layout consist of the following:
- Insurer Name and Address Fields (formerly field numbers 11 through 16)
- Attorney Name and Address Fields (formerly field numbers 12 through 26)
- Group Insurance Policy/DOL (formerly field 27)[12]
From the authors’ perspective regarding the removed fields, while the 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 in order to return the DOL.
File Name formats have been added
Finally, as CMS had also indicated in their summary of changes, updated information regarding file name formats has been added to Chapter IV, Section 10.2 for those RREs utilizing a Connect:Direct file transmission method.[13] 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[14]
- Where:
While this will be helpful for those RREs utilizing Connect:Direct as their file transmission method, the vast majority of RREs and third party submission agents submit files to CMS using SFTP or HTTPS. Unfortunately, CMS have still not provided file naming conventions specific to SFTP or HTTPS. This is an important piece of missing information from a technical implementation perspective. Hopefully this is something which CMS may share shortly in advance of the upcoming July go live date.
For more information on CMSs upcoming Section 111 NGHP Unsolicited File Opt-In Process, see our article summarizing CMS’s recent webinar on this topic - CMS holds webinar to discuss the Section 111 Non-Group Health Plan (NGHP) Unsolicited Response File “opt-in” feature (starts July 2023)
‘NOINJ’ Code (Liability Claims) – reporting of ‘NOINJ’ code is now optional
In the Summary update page to Chapter IV, CMS states: “[f]or liability claims, it is now optional to report ‘NOINJ’ codes in certain circumstances (Section 6.2.5.2).”[15]
As indicated above, CMS is now making it “optional” to report 'NOINJ’ codes in limited circumstances which meet the agency’s criteria per Chapter IV, Section 6.2.5.2. In general, this relates to certain cases where, as CMS states, the “type of alleged incident typically has no associated medical care and the Medicare beneficiary/injured party has not alleged a situation involving medical care or a physical or mental injury.”[16]
As examples, CMS references such claims as “loss of consortium, an errors or omissions liability insurance claim, a directors and officers liability insurance claim, or a claim resulting from a wrongful action related to employment status action.”[17] Up until this update, CMS has historically required reporting in these situations, in pertinent part, if “medicals are claimed and/or released or the settlement, judgment, award, or other payment has the effect of releasing medicals.”(CMS italics and bold).[18]
In these situations, CMS’s longstanding instructions have required “the RRE to report claim information in these circumstances. However, in these very limited circumstances, when the claim report does not reflect ongoing responsibility for medicals (ORM) and the insurance type is liability, a value of “NOINJ” may be submitted in Field 18 (ICD Diagnosis Code 1).” (CMS bolding).[19]
However, now as part the NGHP User Guide (Version 7.2) updates, CMS states that the reporting of cases meeting ‘NOINJ' criteria per Section 6.2.5.2 is “optional” with the agency stating as follows on this point in the new User Guide:
Note: In cases where the reporting of a liability record only meets the criteria for reporting a ‘NOINJ’ diagnosis code in Field 18, the reporting of the record is no longer required. However, it is optional for the RRE to report the record with the ‘NOINJ’ diagnosis code following the previously existing rules in the User Guide as follows: When submitting the ‘NOINJ’ value in Field 18, all of the rest of the diagnosis fields must be left blank and Field 15 (Alleged Cause of Injury, Incident, or Illness) must be submitted with the value “NOINJ” or all spaces. All other required fields must be submitted on the claim report.[20]
With respect to the now optional reporting of ‘NOINJ’ codes for qualifying cases, CMS continues to list several “important considerations” to ‘NOINJ’ reporting, for those RREs who opt to continue to report this code. These considerations are stated, in full, in the endnote to this sentence for the reader’s convenience.[21] Further, click here to review Section 6.2.5.2 in full.
ORM termination – physician statement (ORM termination “date”)
In the Summary update page to Chapter III, CMS states: “[t]he guidance on determining the ORM termination date based on a physician statement has been clarified (Section 6.3.2).”[22]
As part of Chapter III, Section 6.3.2, CMS outlines certain instances regarding ORM termination. One of the items discussed involves situations where an RRE, as CMS states, “is relying upon a physician’s statement to terminate ORM.”[23] In relation to this, CMS’s update in the new User Guide on this topic relates to what ORM termination “date” should be used by the RRE when terminating ORM based on a physician statement.
In this regard, CMS provides the following guidance as part of its NGHP User Guide (Version 7.2) updates:
Where an RRE is relying upon a physician’s statement to terminate ORM, the ORM termination date to be submitted should be determined as follows:
- Where the physician’s statement specifies a date as to when no further treatment was required, that date should be the reported ORM termination date;
- Where the physician’s 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 physician’s statement does not specify a date when no further treatment was required, nor is the statement dated, the last date of the related treatment should be used as the ORM termination date.[24]
Of note, while CMS’s new updates did not make changes to the agency’s technical requirements regarding the type of information which should be included in the physician statement, RREs may wish to review CMS’s guidance on this point in conjunction with CMS’s updates stated above. While a discussion of CMS’s requirements for the physician statement is beyond the scope of this article, the authors include certain information on this point in the endnote to this sentence to help the RRE as part of their review.[25]
ORM trigger guidance clarification
In the Summary update page to Chapter III, CMS states: “[g]uidance on what triggers the need to report ORM has been clarified (Sections 6.3 and 6.5.1.1).”[26] Of note, while CMS references Section 6.5.1.1, that section does not relate to CMS’s ORM trigger guidance. Rather, that section relates to the above ‘NOINJ’ information.
To begin review of these updates, it is noted that as part of Section 6.3 CMS outlines, in some detail, certain ORM definitional components and other technical points regarding the ORM reporting. As part of the new User Guide updates, CMS, from the authors’ review, has made certain verbiage changes to one specific area of Section 6.3. Unfortunately, CMS did not explain the exact changes made, or use track changes to help denote what was removed, added, modified, etc.
Thus, from the authors’ comparison of Section 6.3 as contained in the previous User Guide (Version 7.1) with the changes made to these sections as now contained in the new User Guide (Version 7.2), the authors believe the below reflect the verbiage changes made by CMS (with the authors using track changes and bolding to help better identify the updates):
The trigger for reporting ORM is the assumption of ORM by the RRE—when the RRE has made a determination to assume responsibility for ORM, or is otherwise required to assume ORM— not when (or after) the first payment for medicals under ORM has actually been made. and when the beneficiary receives medical treatment related to the injury or illness. Medical payments do not actually have to be paid for ORM reporting to be required.[27]
In reviewing the new verbiage above, CMS has added a second element in terms of when ORM is established by adding the verbiage “and when the beneficiary receives medical treatment related to the injury or illness” and eliminated the concept when the RRE is “otherwise required to assume ORM.” Thus, based on the above verbiage changes, it would appear reasonable to conclude that the RRE assumes ORM when (1) the RRE has made a determination to assume responsibility AND (2) the beneficiary receives medical treatment related to the injury or illness.
The verbiage updates represent a significant change to CMS’s longstanding position that ORM is assumed when the RRE has made a determination to assume ORM. Now, per this update and CMS’s use of the conjunctive “and” in the revised verbiage, in addition to the RRE’s determination to assume ORM, the second component (“the beneficiary received medical treatment related to the injury or illness”) would also need to be met to establish ORM assumption. This could have significant practical impact as, under the old rule, there could be situations where an RRE would have ORM by its “determination” to assume ORM, but the claimant does not actually receive any medical treatment.
However, a possible complicating wrinkle to what may be considered a logical interpretation of the new verbiage as stated by the authors in the two preceding paragraphs could arise from CMS’s retention of the phrase “Medical payments do not actually have to be paid for ORM reporting to be required.” From the authors’ perspective, retention of this phrase could be viewed as potentially contradictory and could create issues in terms of practical application. For example, one may question how an RRE might be expected to know, subsequent to initial notification of an injury or illness for which no treatment had been sought at the time, whether treatment had actually been subsequently received without a claim having been submitted to the RRE to alert them to that fact.
Notwithstanding this potential interpretative complication, overall, CMS’s updates to Sections 6.3 and 6.5.1 can be viewed as taking steps toward better refining the definition ORM assumption. Going forward, this may be an area for further (and better) clarity and guidance from CMS. In the interim, click here to review Section 6.3 in full.
HEW Software
In the Summary update page to Chapter V, CMS states: “[t]he end-of-line character has been clarified for files using HEW software (Appendix E).”[28] Regarding this update, CMS added the following information within the introduction to Chapter V, Appendix E: “The HEW software uses a line feed (LF; \n, 0x0A in hexadecimal or 10 in decimal) rather than a carriage return (CRLF) to separate records.”[29] For those reporters utilizing CMS’s free HEW software to perform EDI 270/271 translation for their Query Input and Query Response Files, this may be a helpful point of clarification.
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, Summary of Version 7.2 Updates, p. 1-1.
[2]CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter IV, Summary of Version 7.2 Updates, p. 1-1.
[3] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter IV, Section 7.5.
[4] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter V, Appendix N.
[5] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter V, Section 7.5.
[6] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter IV, Section 7.5, Table 7-3.
[7] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter IV, Section 7.5, Table 7-3.
[8] 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-4.
[10] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter IV, Section 7.5, Table 7-4.
[11]CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter V, Appendix F.
[12] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter V, Appendix F.
[13] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter IV, Section 10.2.
[14] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter IV, Section 10.2.
[15] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter IV, Summary of Version 7.2 Updates, p. 1-1.
[16] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter V, Section 6.2.5.2.
[17] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter V, Section 6.2.5.2.
[18] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter V, Section 6.2.5.2.
[19] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter V, Section 6.2.5.2.
[20] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter IV, Section 6.2.5.2.
[21] On this point, CMS states follows:
Note: In cases where the reporting of a liability record only meets the criteria for reporting a ‘NOINJ’ diagnosis code in Field 18, the reporting of the record is no longer required. However, it is optional for the RRE to report the record with the ‘NOINJ’ diagnosis code following the previously existing rules in the User Guide as follows: When submitting the ‘NOINJ’ value in Field 18, all of the rest of the diagnosis fields must be left blank and Field 15 (Alleged Cause of Injury, Incident, or Illness) must be submitted with the value “NOINJ” or all spaces. All other required fields must be submitted on the claim report.
Important Considerations:
- The default code of ‘NOINJ’ may not be submitted on claim reports reflecting ORM. If a Claim Input File Detail Record is submitted with Y in the ORM Indicator (Field 78) and either the Alleged Cause of Injury, Incident, Illness (Field 15) or any ICD Diagnosis Codes 1-19 (starting at Field 18) contain ‘NOINJ’, the record will be rejected.
- The default code of ‘NOINJ’ may only be used when reporting liability insurance (including self-insurance) claim reports with L in the Plan Insurance Type (Field 51). If the Plan Insurance Type submitted is not L, the record will be rejected.
- ‘NOINJ’ will only be accepted in Fields 15 and 18 on the Claim Input File Detail Record. If ‘NOINJ’ is submitted in any of the ICD Diagnosis Codes 2-19 starting in Field 19, the record will be rejected.
- If ‘NOINJ’ is submitted in Field 15 then ‘NOINJ’ must be submitted in Field 18; otherwise, the record will be rejected.
- If ‘NOINJ’ is submitted in Field 18, then ‘NOINJ’ (or all spaces) must be submitted in Field 15; otherwise, the record will be rejected.
- If ‘NOINJ’ is submitted in Field 18, then all remaining ICD Diagnosis Codes 2-19 (Fields 19-36) must be filled with spaces. If Fields 19-36 contain values other than spaces, the record will be rejected.
- If an ‘NOINJ’ code is incorrectly or inappropriately used, the record will be rejected with the CI25 error code.
- CMS will closely monitor the use of the ‘NOINJ’ default code by RREs to ensure it is used appropriately. RREs using this code erroneously are at risk of non-compliance with Section 111 reporting requirements.
CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter V, Section 6.2.5.2 (CMS emphasis).
[22] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter V, Section 6.3.2.
[23] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter V, Section 6.3.2.
[24]CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter V, Section 6.3.2.
[25] On this point, CMS provides, in part, as follows in Section 111 NGHP User Guide (Version 7.2), Chapter IV, Section 6.7.1:
Note: There is a limited “Special Exception” regarding reporting termination of ORM:
- Assumption of ORM typically occurs with respect to no-fault insurance (as defined by CMS—see Record Layout descriptor for CMS’ definition) or workers’ compensation. Because this may involve all levels of injury, the above rule could result in the continuation of open ORM records even where, as a practical matter, there is no possibility of associated future treatment. An example might be a relatively minor fully healed flesh wound that occurred in a State where workers’ compensation requires life-time medicals. To address this situation, RREs may submit a termination date for ORM if they have a signed statement from the injured individual’s treating physician that the individual will require no further medical items or services associated with the claim/claimed injuries, regardless of the fact that the claim may be subject to reopening or otherwise subject to a claim for further payment.
- If, in fact, there is a subsequent reopening of the claim and further ORM, the RRE must report this as an update record with zeroes or a new date in the ORM Termination Date (Field 79).
[26] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter III, Summary of Version 7.2 Updates, p. 1-1.
[27] CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter III, Section 6.3.
[28]CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter V, Appendix E.
[29]CMS’s Section 111 NGHP User Guide (Version 7.2, June 5, 2023), Chapter V, Appendix E.
