One of the biggest struggles in EDI 834 processing is understanding the different ways each exchange sends their files. For example, the FFM can send a code from their file that symbolizes something different than the NYS Health Exchange code. This makes processing files through the same system very difficult, until Softheon found a way to unify the data.
834 Benefit Enrollment and Maintenance
If you work in the healthcare industry, you’ve probably heard the term “standard EDI format.” An EDI (Electronic Data Interchange) is any kind of data sent electronically, typically through coded segments. The specific type of EDI used for healthcare enrollments is an 834 file. Although the 834 has a standard format, it doesn’t necessarily mean all exchanges will send the values the same way. The way the Federally Facilitated Marketplace (FFM) files are configured are not always the same as the way a State Based Exchange file is configured. Although the 834 has an “industry standard,” there are several ways to interpret values, also known as “mutually defined.” For some exchanges, that could be a subscriber ID, for others it could be a policy ID. Additionally, there are segments that are considered “situational,” meaning they’re dependent on other segments being present. For other exchanges, these dependencies can differ. This can lead to a problem when processing the data.
The Softheon Advantage: Normalization
Softheon has designed an innovative process called Normalization. We can rearrange data in our system that will allow all files to be reviewed and processed the same way. When Softheon imports an 834 file, each transaction is represented by a folder entity in our system. Once the data is imported into these folders, called member details, Normalization will process and rearrange the data into a uniform state.
Many Ways In, New Way Out
Softheon receives data from the FFM, several state-based exchanges, and issuer off-exchange populations. Each data source sends their 834 files differently. Other files received from the exchanges are also processed through Normalization, such as PreAudit files, RCNO files, etc. Softheon has created a product that will absorb all the various data and translates it into a Softheon Member Detail folder.
Unification
As mentioned, each data source sends files differently. When Softheon translates this into a member detail folder, it gets rearranged into a uniform state. The member detail folder is a literal translation of the various loops and segments from the 834, specifically the 2000-2750 loops for each specific member of the transaction set. Doing this allows Softheon to process the data throughout the entire end to end workflow in the same manner, so every successive step can map to the same value in the member detail folder, regardless of which data source sent it.
Preservation of Data
Now it may seem like Normalization is changing data, but it is simply rearranging it. All original data is preserved. It is extremely important to preserve the original data so it can be reconciled with the exchange.
For more information or to schedule a demo, please email us at info@softheon.com.
The views and opinions expressed by the authors on this blog website and those providing comments are theirs alone, and do not reflect the opinions of Softheon. Please direct any questions or comments to research@softheon.com.