Healthcare IT EMR PMS

EDI 5010 Documentation 837 Professional - Loop 2300 Date information

Payer Claim Number aka Internal Control Number (ICN) or Claim Control Number (CCN)

Payer Claim Number (ICN/CCN) – Understanding Its Importance in Claim Processing

A Payer Claim Number, also known as an Internal Control Number (ICN), Claim Control Number (CCN), or Document Control Number (DCN), is a unique identifier assigned by a payer to track a claim within their internal system.

Significance of the Payer Claim Number in Claim Processing

To fully understand the role of this number, let’s go through the typical claim processing workflow:

Healthcare entities such as provider offices, facilities, hospitals, and laboratories generate claims for patients and submit them to payers via Electronic Data Interchange (EDI) or paper claims (CMS-1500 form).
Upon receipt, the payer validates the claim, performs necessary error checks, and enters the claim into their internal processing system. At this stage, a unique claim number is generated for future reference.
The payer then determines their financial responsibility through a process known as claims adjudication. The claim may be approved for full payment, partially paid, or denied based on coverage and policy rules.
An Explanation of Benefits (EOB) is then issued to the provider, detailing the payment decision and any applicable denial reason codes. The payer includes the Payer Claim Number in both the EOB (paper format) and the Electronic Remittance Advice (EDI 835).

Why Is the Payer Claim Number Essential for Claim Resubmissions?

When a claim is denied, the healthcare provider must correct and resubmit it for reconsideration. In this process, the inclusion of the original Payer Claim Number—as provided in the EOB or EDI 835—is mandatory.

This number allows the payer’s system to quickly recognize that the claim is a resubmission rather than a new claim, facilitating efficient processing. Most payers will not accept resubmissions that do not reference the original Payer Claim Number.

For detailed submission guidelines, refer to specific payer instructions such as the BlueCross BlueShield resubmission policy, which mandates the inclusion of the Payer Claim Number.

How to Retrieve the Payer Claim Number from an ERA 835 File

The Payer Claim Number can be located in the CLP segment of the ERA 835 file at the 7th position. Below is an example:


TS3*003448478501*12*20201231*2*96
CLP*143155*19*48*0**HM*20C783340200*12*1
NM1*QC*1*XXXXX*XXXXX M*M***MI*521106302

In this case, 20C783340200 is the Payer Claim Number.

Best Practices for Recording the Payer Claim Number in PMS Software

Most Practice Management Software (PMS) solutions include a designated field for entering the Payer Claim Number during manual payment posting. However, payment posters often overlook this field, leading to inefficiencies in claim tracking.

To ensure accuracy:

Train payment posting teams on the importance of capturing this number.
Implement a system validation that requires entry of the Payer Claim Number when processing denied claims.
For claims with zero payments, enforce the entry of both denial codes and the Payer Claim Number before finalizing the posting.

Including the Payer Claim Number in EDI 837P Resubmissions

When resubmitting a claim via EDI 837P, the Payer Claim Number must be inserted in Loop 2300 REF Segment. Below is a sample format:


CLM*214170*64.00***12:B:7*Y*A*Y*Y
REF*F8*185274314700919

Here, REF*F8*185274314700919 references the original Payer Claim Number within the EDI 837P file.

Conclusion

By ensuring that the Payer Claim Number is accurately recorded and referenced during claim resubmissions, healthcare providers can significantly improve the efficiency of their claim processing and reduce unnecessary denials. Compliance with payer-specific guidelines is key to seamless reimbursement.

Parse EDI 835 Message into JSON

Claim Forward to Other Payer

Understanding X12 EDI Structure

Understanding EDI Structure

Introduction

Before diving into the EDI (Electronic Data Interchange) structure, let's first understand how data is typically structured in a book or a Word document.

Structure of a Page

Word: A single unit of language separated by space.
Sentence: A group of words forming a meaningful statement.
Paragraph: A collection of sentences expressing a complete idea.

Example of Address Representation

Subscriber Information

Carrie J. Brown, DOB 01/13/1953, Male
3360 Lynn Street
Woburn, MA 01801

Page vs. EDI Structure

Traditional Document	EDI Structure
Words are separated by spaces	Elements are separated by a delimiter (usually `*`)
Sentences are separated by lines	Segments are separated by a terminator (usually `~`)
Paragraphs are separated by line breaks	Loops do not have defined separators

Converting Data to EDI Format

Using EDI formatting, the above address example is converted into:

Carrie*J*Brown*01/13/1953*Male~
3360*Lynn Street~
Woburn*MA*01801~

Healthservices LLC*xx1234512~
2550*Adamsville Road~
Harlingen*TX*78550~

Note: In real-world EDI, this appears as:

Carrie*J*Brown*01/13/1953*Male~3360*Lynn Street~Woburn*MA*01801~Healthservices LLC*xx1234512~2550*Adamsville Road~Harlingen*TX*78550~

How Computers Process EDI Data

Computers do not inherently understand the meaning of raw EDI data. To structure it properly, we use:

Segment Name - Identifies the type of data.
Type Qualifier (Optional) - Specifies what the segment represents.

Rewriting the Example with Proper EDI Segments

NM1*IL*Carrie*J*Brown*01/13/1953*Male~
N3*3360*Lynn Street~
N4*Woburn*MA*01801~

NM1*85*Healthservices LLC*xx1234512~
N3*2550*Adamsville Road~
N4*Harlingen*TX*78550~

Key Points

✅ Each segment starts with a segment name (e.g., NM1, N3, N4).
✅ Type qualifiers (e.g., IL, 85) differentiate data types.
✅ Address segments (N3, N4) do not require a type qualifier.

Additional Notes on EDI Messages

If you need to send a number (NPI, Tax ID, SSN), it must be prefixed with an identifier.

NM1*85*2*Demo Clinic*XX*1215099528

Since segments are groups of elements, some elements may be optional.

With a middle name:

NM1*IL*Carrie*J*Brown

Without a middle name:

NM1*IL*Carrie**Brown

Conclusion

EDI structures transform unstructured text into computer-readable formats. By using segments, delimiters, and type qualifiers, we create a standardized way to exchange data efficiently.

Before Jumping to EDI Structure, let us understand what is a Page in a book or word document?

Structure of the Page

Word	A word is a single unit of language that can be represented in writing or speech and each word is separated by space.
Sentence	A combination of a group of words that gives a complete meaning and each sentence separated by a line
Paragraph	A combination of a group of sentences that gives a complete meaning

Let us see an example of two addresses using the above structure. Assume that we need a subscriber(insurer) address and Company address in the document.

Let us name the below paragraph as Paragraph 1 and contains Subscriber information.
Carrie J. Brown, DOB 01/13/1953, Male
3360 Lynn Street
Woburn, MA 01801
Let us name the above paragraph as Paragraph 2 and contains Company information with a tax id.
Healthservices LLC, Tax ID: xx1234512
2550 Adamsville Road
Harlingen, TX 78550
Page Vs EDI

Page in a Book	Message in an EDI
Word	Elements
Sentence	Segments
Paragraph	Loop

Separators

Page in a Book	Message in an EDI
Words are separated by space	Elements as separated by a delimiter. Any Character can be a delimiter, but most used is Asterisk *
Sentence are separated by Line	Segments as separated by the terminator. Any character can be terminator, but most used is ~
Paragraph are separated by one or more lines	There are no separators for Loop

Let us rewrite our examples in EDI Structure.

Carrie*J*Brown*01/13/1953*Male~
3360*Lynn Street~
Woburn*MA*01801~

Healthservices LLC*xx1234512~
2550*Adamsville Road~
Harlingen*TX*78550~

Just for better understanding, the above information is separated with a newline character, but in real-time, it will look as follows

Carrie*J*Brown*01/13/1953*Male~3360*Lynn Street~Woburn*MA*01801~Healthservices LLC*xx1234512~2550*Adamsville Road~Harlingen*TX*78550~

Now let us get into more detail by looking at the above message. There are some issues for the computer to understand as follows.
1) Very first, the computer does not know what we are talking about, but we know that the above is two address representations where one is for the subscriber and one is for the company.
2) So, it is time to give information in a more structured way to the computer about this data.

X12 EDI expects before you start giving information, it needs a segment Name and segment type. Whenever we need to provide information about an entity or person, then the segment name is NM1. Second, we need to inform what is that entity or person, are its Patient details or is it Company Name, etc. That is called type qualifier, for example, for the subscriber, the type qualifier is IL and for Company, the type qualifier is 85, etc

Segments should start with Segment Name, optionally there should be segment type or type qualifier.

Let us rewrite our examples in EDI Structure

NM1*IL*Carrie*J*Brown*01/13/1953*Male~
N3*3360*Lynn Street~
N4*Woburn*MA*01801~

NM1*85*Healthservices LLC*xx1234512~
N3*2550*Adamsville Road~
N4*Harlingen*TX*78550~

As you can see, every segment starts with segment names such as NM1, N3, N4, etc and optionally it also contains type in the second position. An important point to note that is, for address segments, there is no need to provide type.
Other important notes on EDI Message
1) If you want to send any number such as NPI or tax ID or SSN, then before that number we need to tell what that number is. For example, the provider contains NPI number, so before we put the actual NPI number, it should be prefixed by XX as follows1) If you want to send any number such as NPI or tax ID or SSN, then before that number we need to tell what that number is. For example, provider contains NPI number, so before we put the actual NPI number, it should be prefixed by XX as followsNM1*85*2*Demo Clinic*XX*1215099528

JSON to EDI 270 Eligibility and Benefit Inquiry

Summarize all table row-counts in a single query

Provider Identifiers

When we send claims to the insurance companies, it is very important to give the different provider numbers or identifiers for processing the claim. Let us understand different provider numbers.

DEA (Drug Enforcement Administration) Number

This is a unique number that is issued to every provider that prescribes any type of controlled medication.

What is Controlled Medication

Most prescriptions for infections or for chronic conditions are non-controlled. For example, most blood pressure and cholesterol medications, diabetes medications, asthma inhalers, and antibiotics are all non-controlled medications.

Controlled substances are medications that can cause physical and mental dependence, and have restrictions on how they can be filled and refilled. They are regulated and classified by the DEA (Drug Enforcement Administration) based on how likely they are to cause dependence. Some examples of controlled prescription drugs include :Morphine,Oxycodone,etc

EDI 837 Professional Loops

EDI RESTful Web Service API

Are you looking for RESTful Web Service API to generate HIPAA X12 EDI Transactions? Then here is the solution offered. Please contact me for more details

Create an account in our Nagata EDI Tool and check HIPAA X12 EDI Transactions sets.
Here is the demo link
https://demo.nagatabilling.com/NagataEDITool/login.zhtml

ASC X12 270: Eligibility, Coverage, or Benefit Inquiry.
This transaction allows providers to check whether a patient has insurance coverage as of a specified date. This transaction is typically sent by healthcare service providers, such as hospitals or medical facilities, and sent to insurance companies, government agencies like Medicare or Medicaid, or other organizations that would have information about a given policy.

Minimum information such as Member Name, Date of birth and gender or subscriber ID is required to submit in the 270 message to get the response. If we are doing real time mode, then the expected response time will be 1 to 2 seconds.

Sample Workflow

1. Provider Smith uses ABC Billing Software aka Practice Management Software(PMS).
2. Provider Smith already signed up with XYZ Clearing House and an ID has been assigned to Provider Smith by the clearinghouse.
3. ABC Billing software has the option of generating EDI 270 messages and through web service call, it will send the message to the clearinghouse.
4. XYZ receives a message within a few seconds and then identifies the message for Payer Cigna. Since XYZ already enrolled with Payer Cigna, so it just forwards the message to Payer Cigna via web service.
5. Payer Cigna receives the message and prepares response 271 and sends it back to the clearinghouse. Immediately clearing house forward the response to the Provider Smith’s ABC billing software.
6. ABC Billing software parse the EDI 271 Message into Human-readable text and show it to the user.

Download sample EDI 270
Download Sample EDI 271
Parse EDI 271 To HTML
Parse EDI 271 To Text
Parse EDI 271 To JSON

Parse EDI 837p Message into JSON

EDI 837 P Budget Number Example

Hire me

You can hire me for any of the following

Training on X12 EDI Transactions to support your current job.
If you already developed EMR and planning to add Billing Component as an integrated solution, then you can hire me to help your team both functionally and technically.
You already have an inhouse development team and want to work with your team to enable all the EDI transactions, then you can hire me to support both Technical and Functional areas.
You already having an inhouse development team and looking for Restful Webservice API to generate X12 EDI transactions, then you can hire me to deliver the source code for the same. I've developed Restful Webservice API using Latest spring Boot version for all the Healthcare EDI transactions EDI RESTful Web Service API
If you are having an RCM Billing company and if you would like to automate some of your routine billing works, then you can hire me to develop/design/help for the software. I’ve 5 years of experience as RCM Manager.3 If you are developing or planning to develop EMR/EHR/Medical Billing Application/Practice Management System, you can hire me as a subject matter expert for both Technical and functional areas. I can help to develop the application from scratch To end go-live mode. This arrangement involves the following responsibility

Database Design (MySQL or SQL Server)
UI Design Ideas
Java Spring Boot web API Source code
Reporting
Dashboards

Parse EDI 271 Health Care Eligibility Benefit Response

Medical Billing Terminology

Mysql Query for Aging To Count No of records

JSON to EDI 837 P

Are you looking for creating X12 EDI 837p using JSON Format? Here is the solution offer. Please contact me at vbsenthilinnet@gmail.com for more details.

Sample Webservice Call

Internal Tool demo to Test the Webservice call

Are you looking for a solution to generate 837P or 837I in your medical billing product? Then you are in the right place.

I am Senthil Muthiah, A technology-driven professional with over 20 years of experience including nearly 9 years in Software Development and Business Analysis. Well versed with US Healthcare Domain – Electronic Medical Record (EMR) & Medical Billing. In particular, 15 years of experience in the Healthcare domain specifically in Claim processing, Claims adjudication, clearing house-related processes.

Consultation Option

1. if your product is in java, then we are very close. You can buy my java Spring Boot API Service source code which converts JSON to EDI and vice versa.

Here is the demo link
https://demo.nagatabilling.com/NagataEDITool/login.zhtml

2. if your product in different technology, then I will help your developer to create an EDI file using Pseudo. Here is a sample Pseudocode

For more detailed resume and skills, please refer to the following link

· Online Resume

· Linked Profile

My Email ID : vbsenthilinnet@gmail.com
Mobile : (91) 95351 609 48 (India)

X12 EDI Examples