What are HIPAA SNIP types? We get this question a lot, so we’ve been blogging about the different categories WEDI has defined to validate healthcare EDI transactions. Thus far, we’ve covered:
SNIP 1 & 2 Integrity and Requirement Testing
SNIP 3 Claim Balancing
SNIP 3 Remittance Advice Balancing
SNIP 4 Intersegment Situational Testing
SNIP 5 External Code Set Testing
These rules are sometimes referred to as SNIP levels – although that may wrongly imply that each type builds upon the previous category. In actuality, each SNIP type is a standalone set of validations rules.
In this article, we’ll focus on SNIP 6.
SNIP 6 enforces situational rules specific to service lines and products. While SNIP 4 also focuses on situational rules that analyze the relationships between loops, segments and elements, SNIP 6 differs in that the rules apply to subsets within the transaction sets.
For example, within an 837…
Workers compensation claims contain a special set of requirements when submitted in the EDI 837 format. This article describes these specific characteristics.
In a standard 837, the 2000B loop always contains subscriber information (the primary insured individual). Claim level information (2300 loop) is nested beneath the 2000B loop in this scenario. The 2000C (Patient) loop is present in the case in which the claim is related to a dependent of the subscriber. In these cases, the 2300 loop is nested under 2000C. In workers comp claims, a 2000B and 2000C loop always exist, and their purposes are a bit different. Information related to the employer goes into the 2000B loop, while the 2000C loop is used for the claimant (the injured worker). The concept of a dependent doesn’t exist in workers comp claims.
The SBR segment present in 2000B is a required…
Each day health plan administrators look forward to the challenge of loading 834 enrollments and 837 claims into their adjudication systems.
From a distance, it seems simple to report and reconcile the EDI transactions submitted by providers and clearinghouses through a plan’s intake workflow. Drilling into the steps along the inbounding process, challenges emerge which can present insurmountable obstacles to answering a question as basic as: How long has this claim been held up in my intake process?
TriZetto QNXT is a common adjudication platform we’ll use to illustrate this point. In a typical workflow, loading claims might involve:
Handoff: The day’s 837s are pulled from an SFTP server and moved to the start of the intake process.
Archive: Move files into processing workflow, and archive a copy.
EDI Structural Validation – Basic checks are performed to ensure the 837 transactions are well-formed. This level of validation is…
Exporting X12 837 claim files into standardized CMS1500 or UB-04 forms is simple with T-Connect X12 Studio Toolbox’s PDF Claim Form Generator. CMS1500 is the standardized form for X12 837P (Professional) EDI files. The CMS1450, aka UB-04, provides the form for 837I (Institutional). Both forms are provided by the Centers for Medicare & Medicaid Services (CMS). The PDF claim files can be used to view, archive, or manage EDI claims into a human-readable form. Our Claim Form Generator feature is a very useful tool for EDI Analysts, overlaying 837 EDI data onto industry-standardized forms.
Steps to Generate the PDF 1500CMS or UB04 Forms
To start, download X12 Studio and install the application:
Launch the application and open an existing 837I or 837P X12 EDI format:
Click on the Generate PDF icon in the top menu:
View the Output tab at the bottom of the application. This…
Ensuring that 837 EDI transactions meet validity checks is critical to improving auto-adjudication and encounter submission acceptance rates. SNIP Type 3 describes the rules for balancing header and detail levels of the Claim, Premium Payment and Remittance Advice transaction sets. Previously, our blog covered the logic required to balance 835 transactions. Now we’ll look at the steps necessary to balance claims with service lines, including Coordination of Benefits loops in multiple payer scenarios.
Claims and encounters may be represented by a variety of X12 transaction types: 837 Professional, Institutional and Dental, as well as their corresponding post-adjudicated variants (298, 299, 300), intended for submission to All-Payer Claims Databases. The following logic applies to all versions of the 837 equally, with a few caveats noted below.
Rule 1 – Balancing Claim Charge Amounts
The first claim balancing rule is straightforward: given the parent-child relationship of 2300 claim loops to their 2400 service…
As we strike out into 2018, the implementation of All-Payer Claims Databases (APCD) across states remains variable and dynamic. Massachusetts maintains a comprehensive implementation, aggregating data feeds from over 80 public and private payers. Massachusetts has leveraged their APCD to create a state-specific risk adjustment model to meet the ACA provision which balances funds from healthier populations to higher risk pools. Late in 2016, Minnesota concluded a feasibility study which determined their APCD could significantly improve risk adjustment vs. the federal model.
On the other hand, West Virginia and Tennessee have put APCD development on hold. California payers optionally submit claims and encounters to a public benefit corporation. Legal, fiscal and political concerns guarantee a fluid situation for insurers.
This blog post is focused on the technical obstacles that health plans face in states requiring APCD submission. Since these databases have phased in over the last decade through both voluntary and legislated…
The X12 HIPAA transaction set is used across the healthcare industry to transmit claim, enrollment and payment information. Given the importance and ubiquity of these EDI files, you might assume that translating them from ANSI to a relational database format would be well-supported with a range of options.
In practice, a task as common as parsing a claim or encounter and storing it in a database can quickly escalate into a significant problem.
One solution we’ve seen involves archiving a snapshot of the EDI file using filestream storage. This can satisfy some retention requirements, but provides little in terms of fine-grained tracking or analytic capabilities.
A more complete approach is to parse the X12 file into its discrete elements and store them in a relational database. The ideal solution captures the full extent of the EDI transactions while also applying a reasonable leveling of flattening to keep in the number of table joins under control.
TriZetto’s QNXT is a widely adopted platform for claim processing and membership administration. QNXT relies on the Microsoft stack, particularly BizTalk, .Net and SQL Server, to process and store EDI messages.
These technologies give developers many tools for customizing and tracking HIPAA transactions, but the complexity of implementing business rules and lifecycle reporting on EDI data are constant concerns for health plan payers.
Tallan’s T-Connect EDI Management Platform is an optimized integration solution founded on three core design principles:
An accessible API. One of the most common challenges our partners face is implementing business logic on EDI. T-Connect loads all HIPAA transactions into a fully compliant hierarchical data structure that can be manipulated with familiar tools such as Visual Studio and .Net.
Full database persistence. Going from EDI to a relational database is a frequent business need, but capturing the full set of fields present in an 837 alone represents…