Author's Note

The reader should understand when the author mentions claim adjustment(s), he is referring to electronic claim adjustment(s).

The reader should understand the words Transaction(s) and File(s) are interchangeable descriptions.

I prefer to educate users versus spoon feeding step-by-step instructions. However, I understand there are situations when one currently might not have the time to be educated about the why, and instead simply needs the required steps to accomplish a task. So, if you are restricted by time and simply need instructions to adjust claim(s), click here to fast forward. However, I do hope you return later to become informed.

ElderSuite is the most popular Adult Day Care software available, because we strive to give users the ability to complete any administrative task directly from within ElderSuite, without requiring the user to leave the ElderSuite environment and employing third-party tools, and most importantly, without the need to duplicate previous efforts. While our goal is firm, we don't accomplish it 100% of the time. Generally, the cause is out of our control and created by third-party issues or limitations. This thesis applies specifically to electronic claim adjustments...sometimes. I emphasize sometimes, because the ability to accomplish this within ElderSuite varies for reasons beyond our control and depends entirely on the payer which the adjusted the claim(s) is being submitted.

To explain, we first need a short history lesson on the Health Insurance Portability & Accountability Act of 1996 (HIPAA). While HIPAA encompasses many things, for the purposes of this article, we'll focus on HIPAA as a federal statute which includes a separate set of provisions aimed at solving compatibility issues between proprietary systems. So, while focusing only on this portion of HIPAA, this set of provisions is referred to as Administrative Simplification. To summarize Administrative Simplification, it is a mandated Standard for exchanging healthcare information between covered entities and is known more specifically as Electronic Data Interchange (EDI). The EDI Standard is required to be adhered to by law and by any proprietary system used to exchange healthcare information.

I realize that was a mouthful! I'll summarize by saying it allows healthcare providers (i.e. Adult Day Care providers) to use proprietary systems (i.e. ElderSuite) to communicate and exchange healthcare information electronically with other proprietary systems (i.e. Clearinghouse and Payer internal systems) by following the mandated EDI Standard.

What's all this stuff about Standards?
Standards are all around us, most just don't notice them. However, they are very necessary because they provide people and organizations with a basis for mutual understanding. Standards are used to facilitate communication, manufacturing, e-commerce, and measurement. For example, nuts, bolts, and screws are created by using a Specification Standard. If there wasn't a Standard in place for these items, you would need a special tool anytime you needed to tighten a screw or loosen a bolt. I'm sure you've run across an odd screw head on some device that you can't unscrew or tighten because you don't have the required tool. When such specialty hardware is used it's more than likely a conscious decision made by the manufacturer which helps deter users from opening. However, imagine if every screw you encountered required such specialty tools just to tighten or loosen when necessary. It would make that Philips screw driver you keep in your kitchen cabinet drawer useless and worse imagine how expensive, time consuming, and frustrating it would be keep the so many tools around for simple tasks. This is the problem Standards solve. 

The same necessity for Standards is found in technology. The best example of a technological Standard which I can think of is the Hyper Text Markup Language (HTML) Standard. You may not even be aware of its existence, but you'll likely understand this example. The HTML Standard is used across the Internet for creating and viewing documents on the Internet. These documents are referred to as Web Pages and they are created using HTML. The HTML Standard allows different users with different web browsers running on different device types to view web pages. Actually, this article you are reading is created using HTML and the HTML Standard is the reason you can read it right now. You may be viewing it on your computer in Google Chrome, or an Android Phone or even an iPhone. Other readers may be using Firefox, Internet Explorer, Edge, Safari or any one of the many other available browsers. The fact is that these browsers you use to view web pages are on many different types of devices like computers, phones, tablets, and even TV's among many others. However, they all implement the HTML Standard to make it possible.

My reason for providing these examples is because the claims you submit with ElderSuite are created by utilizing the EDI Standard, ANSI ASC X12 version 5010. Obviously, the biggest difference between the EDI Standard and the HTML Standard is the specifications which explain how each document type should be created. However, the most important difference and the difference which helps ensure one Standard's specifications are followed completely more often than not, is the fact that one is mandated by law.

I'm not a guru on HTML Standards, but don't believe the HTML Standard or any specific version of the HTML Standard is required to be adhered to by by law. It's because of this that not all HTML browsers or all HTML documents are created equally. For example, you've likely noticed a web page which looks different or behaves differently when viewed in a different browser or on a different device. That's because browsers implement the HTML Standard a little different from one to the next. Additionally, there are also variances found in HTML documents because tools used for creating them sometimes don't implement the HTML Standard correctly. This is the cause for many of the differences one might encounter when viewing a website on different browsers.

The EDI Standard, which is mandated by law, requires solutions which exchange healthcare information to use the same version of the EDI Standard. This helps improve several issues. One is that it helps ensure fewer incompatibility issues when exchanging healthcare information. It also assists in easier identification of who is at fault when issues are encountered.
For example, let's say there is an issue with a medical claim exchanged between a healthcare provider and a payer and both entities think it's the fault of the other. Because both entities are required to create and interpret with the latest version of the EDI Standard, we can easily identify who's at fault and quickly resolve the issue. If the transaction submitted isn't compliant based on the current version of the Standard's specification, it's the submitter's issue and the submitter must fix the transaction and resubmit. If the transaction isn't being interpreted accurately using the current version of the Standard's specification then it is the receiver's issue and the receiver must fix their system which reads and interprets the transactions and then re-process the received transaction. How do we know who's at fault? While, this might sound like a tough thing to prove, actually, it's easily accomplished with free tools available online.

Simplicity is the reason Standards are created as they reduce the occurrence of situations like the one described in the example, and they are easily addressed when encountered. Chaos only ensues when Standards are purposely ignored or purposely not implemented exactly as defined by a Standard's specifications. HIPAA benefits the industry because it helps ensure, more often than not, that the EDI Standard is implemented correctly and followed by all entities who are required to use it.

So, now that HIPAA and the EDI Standard are understood, we need to understand that there are specific transaction types for which the EDI Standard applies. However, entities are not required to support all transaction types included in the EDI Standard. Entities can basically pick and choose which transaction types they support or don't support. However, if a transaction type is not supported, healthcare information can't be exchanged with others by enforcing or requiring different formats. For example, a large insurance company (payer) can't require a small provider to submit a claim in a different format because they do not support or prefer not to support the 837 transaction type which is the transaction type required to be used for claim submission. Here is a list of known transaction types: (As noted: Transaction(s) & File(s) are interchangeable)

  • 270 - Eligibility Inquiry
  • 271 - Inquiry and Response
  • 276 - Claim Status Inquiry
  • 277 - Claim Status Inquiry and Response
  • 278 - Authorization Request and Authorization Response
  • 820 - Health Insurance Premium Payment
  • 834 - Beneficiary Enrollment
  • 835 - Remittance / Payment
  • 837 - Claim or Encounter (837I & 837P)
  • 999 - File Acknowledgement

Each transaction or file covered by the EDI Standard consists of mandatory attributes, optional attributes, and some attributes which although optional, enforce additional required attributes if used. The important aspect to understand is that no matter which transaction(s) the sender submits, the transaction(s) must follow the current version of the EDI Standard and the receiver must do the same for interpreting transaction(s).

This was briefly mentioned earlier, but it is important to understand not all transaction types are supported by every sender or every receiver. For example, the 837 transaction type is used to create and submit claims. However, they are actually two separate types of the 837 transaction, 837P (Professional) and 837I (Institutional). Currently, ElderSuite only creates and submits the 837P because it is the only transaction type currently required by ElderSuite users. The 837I has never been requested by any of the providers which use ElderSuite. Please note that if any providers who utilize ElderSuite were ever required to submit the 837I transaction, we would need to update ElderSuite to provide that capability; and, of course, we would enable this compatibility if needed.

A Claim Is A Claim Is A Claim

So, now that you know everything about HIPAA, the EDI Standard, and EDI Transaction Types, it's time to learn why payers won't always accept an electronic claim adjustment.

As the section title hints, the simple truth is that a claim is a claim. If an 837P claim is submitted it doesn't matter who it's from, for what patient it's for, or what payer receives it. It's still an 837P claim and as long as it is compliant with the current version of the EDI Standard it can be processed by a receiver following the same specification. However, that doesn't mean it will be accepted. So, you're saying the initial claim you submit is the same claim as the adjusted claim? Yes, the only difference is any change(s) or adjustment(s) you include. So, why wouldn't the payer accept it? Well, the exact answer to that we will likely never know, but it's going to boil down to something like the scenario below:

You submit a claim for a patient, Name = John Doe, Member ID = 123456789, Date of Service =  01/01/2019, Amount Charged = $30.00.  The payer's system receives the claim, processes the claim, accepts the claim, and sends response notifying you that it has been accepted. Soon after you receive reimbursement. Later, you discovered an administrative error and must adjust the claim. So, you make your adjustment to the claim, Name = John Doe, Member ID = 123456789, Date of Service = 01/01/2019, Amount Charged = ($30.00), and you submit the adjusted claim with the only difference is the Amount Charged is being refunded by changing the previous Charged Amount to a negative value. The payer's system receives the adjusted claim, processes the adjusted claim, denies the adjusted claim, and returns response notifying you it was denied and provides reason for denial. The reason for the denial is some standard message, but likely is attempt to notify you that the claim was denied because the payer's internal system found and existing claim matching the same patient and same date of service found in the adjusted claim. Basically, the payer's system identified the adjusted claim as a duplicate and the payer's internal system will not allow duplicate claims. So, they processed the claim as required, but instead of noticing the changes and accepting the adjusted claim as a refund, they treat it as a duplicate claim and denied it.

Unfortunately, in this situation, the payer will require you to either file a paper correction or visit their web portal to adjust the claim using their system. Although this is a rare occurrence, the fact is that it's still unnecessary and additional work.

I could be wrong, but this issue appears to be nothing more than a technological issue with the internal payer's system and they have't gotten around to implementing the functionality which could address it. The lesson is that just because a payer processes 837P transactions correctly the first time does not mean the payer will process changes to claims at a later time.

Who accepts electronically adjusted claims?

  • Claims submitted to TMHP are Medicaid claims where the payer is HHSC. If this is the payer for the claims you wish to adjust electronically, then you are in luck as it's not a problem. ElderSuite can submit the electronic adjustments successfully just as it does any other claim(s) submitted for HHSC. The adjusted claims will be processed successfully as long as the adjusted claim(s) are submitted within the time period required to be adjusted electronically.

  • If the payer of the claims you are trying to adjust is a Star+Plus HMO/MCO contractor then it's hit or miss

Why do you say hit or miss? 

  1. ElderSuite has been processing claims for contracted Star+Plus payers since it was a pilot program. Several years ago now, when Star+Plus was made official and began enrolling Medicaid members outside of the pilot area (Harris County) and across the rest of Texas, there was not a contracted HMO/MCO payer that accepted electronically adjusted claims. If I recall correctly, while Star+Plus was still in the pilot stages and also during the early stages after it was implemented across Texas, any claim adjustment(s) for the contracted HMO/MCO payers were required to submitted via a paper form which varied among payers. Later however, they began accepting the (standard at the time) Long Term Care Claim Form 1290, which was a paper form used for years by NHIC and TMHP before electronic claims became the norm. Finally, but not all at the same time and also very slowly, the contracted HMO/MCO payers each improved their technological capabilities and began accepting electronic claim adjusts, but only via their respective web portal, as they like to call
  2. Unfortunately but honestly, I simply don't know which payers support which transaction types. We support many different payers and which are used by many ElderSuite subscribers located in many different parts of the country.

In summary, are 2 reasons why I felt it was necessary to provide such an in-depth article on this topic:

  1. We often receive questions on how to process claim adjustments. Instead of constantly repeating the same instructions over and over it was time to provide detailed instructions which users could refer to as needed.

  2. Each time we are asked this question it's difficult to explain the issues and nuances surrounding it and why a user many not be successful with the adjustment. So, we felt we needed to provide additional explanation as to why this option is available and works for some payers, while it doesn't work or isn't available for others.

In conclusion, I hope the information provided in this article has in some way helped those with the perseverance to read this far. Ultimately, I hope you have a better understanding of the varied issues regarding this topic. As promised, the detailed instructions for adjusting claims are provided below.


Important: To summarize the details above, the outcome of your adjustments will be dependent upon ability of the payer to accept adjusted claims via a third-party clearinghouse. Some payers support electronically adjusted claims while others do not. For example, adjusted claims submitted to TMHP are supported because the only payer that requires the use of this clearinghouse supports them. Ultimately, if a user is submitting adjustments to any other payer, the claims could be accepted or they could be denied, but the user can view the results within 24 hours of submitting by downloading reports from the clearinghouse within the ElderSuite Claim Center.

Steps to Adjust Claims

  1. Launch and Sign-In to ElderSuite. When ElderSuite is displayed and ready for use, locate the Claim Center found on the navigation bar. To open, click with your left mouse button.

  2. With the Claim Center displayed, locate the Scrub Claims button found on the Claim Center Screen. To open, click with your left mouse button.

  3. With the Scrub Claims screen displayed, input the Start Date and End Date for the Dates of Service of any claim(s) you wish to adjust. When complete, click the Find button and ElderSuite will retrieve and display, in the Claims List, any claims found matching the Dates of Service provided. If there are no claims found then repeat this step by providing corrected Dates of Service.

  4. On the Claim List, locate the claim you wish to adjust. To open the claim, double-click the located claim with your left mouse button. Optionally, you can open the located claim by selecting it with a your mouse and then clicking the Edit Claim button in the Scrub Claims menu. Either method you choose will result in the claims being open and displayed on the Health Insurance Claim Form - HCFA 1500.

  5. After the claim form is displayed you will need to change the Claim Status  to Pending. To change the Claim Status locate the Claim Status field in the top right-hand corner of the claim form and click the Claim Status field with your left mouse button to display the available options in the field's drop-down list. With the available Claim Status options displayed, select Pending with your left mouse button.

  6. Now, locate the Amount field and adjust your claim by changing to the desired value. *Please Note: If you require your new Amount to be negative, use the minus sign or dash as shown here in quotations: "-". To change the Amount field value from a positive value to a negative value locate and click the Amount field with your left mouse button. Now, simply locate and press the minus sign or dash symbol on your keyboard. After pressing the minus sign or dash symbol the value will be changed from positive to negative and confirmed with the new value displayed inside of parentheses as shown here: ($0.00).

  7. After all desired changes are completed save your changes and close the claim. To save your changes and close the claim, click the Save & Close button using your left mouse button.

After completing all 7 steps, you have adjusted the claim in the ElderSuite database, but you must submit the claim to the payer if you want them to receive this adjustment. Submitting adjusted claims is the same as submitting new claims. So, to submit the adjusted claim, process the adjusted claim as you normally process claims.

After submitting claims you should remember to always check the Claim Status and Inquire Report provided by the clearing house used to submit claims. You can download any reports made available to you by the clearinghouse within ElderSuite Claim Center. Reports are generally available to download within 24 hours of being submitted. Checking the reports for adjusted claims is especially important if you are unsure of the payer's ability to electronically accept and process claim adjustments.

Thanks for listening and I hope you learned something!

Talk soon,

Vincent Cotton


Need software for your Adult Day Care? Users can download ElderSuite at

Support is always available by phone toll-free at +1 888.999.8055


ElderSuite Help Center:


The Ultimate Adult Day Care Software