Splitting 835 Healthcare Claim Payment
The Electronic Data Interchange (EDI) consists of a file in a specific format that represents data exchanged in a transaction from supply chain to healthcare. EDI 835 Claim Payment transaction provides payments information in reference to claims in EDI 837 Healthcare Claim format. The details include transactions such as charges, deductible, copay, payers, payee, etc. The information is stored a hierarchical structure. The standard of EDI format is well defined and the complexity can be very overwhelming. Additionally, we do not want this high degree of detail slowing our processing time.
One of the problems that enterprise systems face with EDI is file size. A single EDI 835 may contain multiple claim records and the quantity of claims in a single file can make it very difficult to process the file. Systems are often bogged down when dealing with a very large file. It also increases risks of failure, which can affect operation cost. Dividing a large EDI file is a logical way to break down a large problem into many smaller tasks. This makes the file easier to work with and reduces the risk of making errors. The key is to maintain integrity of the format while breaking them into smaller pieces. EDI 835: Healthcare Claim Payments are logical candidates for splitting, usually having several groupings of payments possible. We will talk about several popular patterns that a 835 transaction can be split in the proceeding sections.
The simplest case of splitting an EDI file is the ST/SE level split. An EDI file can contain multiple instances of the ST record. In cases where there are several hundreds of ST records or more, there are advantages of storing multiple files that are smaller. Splitting EDI on the ST level is a simple process but can get very tedious as the number of ST records increases. Anyone that has ever worked with EDI text can attest the odds of making mistake navigating through a large file.
The first thing to keep track is the beginning and the end of each transaction. An EDI file consists of one or more transactions wrapped around with the GS/GE loop.
Each transaction starts with the ST and ends with SE tag. The idea to create a new file for each record and reuse the same envelope. In addition, ST02 and SE02 should be set to the same value. Since our new files will only contain one ST each, we can default this value to “0001” for the control number.
One thing to keep in mind is that element GE01 indicates the number of ST records inside the wrapper. If the new EDI file will contain only one ST records, we have to set GE01 to ‘1’ in the new EDI.
Claim Payment Information Level
One of the more common split patterns for EDI835 is on the Claim Payment Information level. The goal is for each file to contain exactly one Claim Payment Information.
As mentioned in the Transaction Split section, the idea is to create a new file for each record that we want to split and reuse envelope. The same idea applies here, but we just have to pick a different envelope for the Claim Payment level.
If we examine the record structure inside of 835, Claim Payment Information repeats at 2100 loop level and is grouped within the 2000 level parent header. We will treat everything outside of Loop 2100 as the envelope and reuse it for each new file created while we split.
A great way to review the newly split files is within T-Connect X12 Studio. X12 Studio is our lightning fast EDI editor which presents the EDI file into a tree structure. This allows for simple navigation through an EDI transaction in it’s true hierarchical structure of loops and segments. Let us look at the 835 sample file opened in X12 Studio. Claim Payment Information repeats twice within Loop 2000 Header level. The split will separate these claim records into two new files.
The results are two new files containing a different Claim Payment Information record. Each one has its own claim record while maintaining the parent structure from the original. One minor detail that’s easy to forget is the number of lines in the new files. The element SE01 reflects the total number of lines in the ST structure. The new file should adjust this element accordingly.
Rule Base Split
More often than not, splitting alone is not enough to refine record keeping. Another popular use case that we have observed among many splitting implementations is grouping Claim Payment Information. Instead of splitting everything on the single record base, we can assign categories for claims to be split into. Now, each file can contain one or more claim records with its own unique category.
For example, using a submitter to group the claims. The element CLP01 is an identifier of each Claim Payment Information. A single instance of 2000 loop can contain multiple claim records. Many of which can belong to the same submitter, say submitter “99”. A new file created can contain just the claim records that came from that has a CLP01 value of “99”.
Splitting is a very useful technique that will help improve EDI management process. There are many more complex scenario on splitting EDI than what was discussed in this post. These implementations can significantly reduce production time and cost when they are deployed effectively.
To begin a conversation with Tallan and see T-Connect in action, contact us today to discuss how we can improve your EDI management capabilities.