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…
Here’s an interesting fact from a Forbes article published earlier this year, regarding end-consumers in the insurance industry:
“91% of non-complainers just leave”1
This tells us that there are two types of customers in the insurance world: complainers, and non-complainers. Among non-complainers, more than nine out of ten actively choose to take their business to another company. The insurer they leave behind must deal with the following consequences:
Loss of future revenue streams
Lack of insight into why the customer chose to leave in the first place
The significance these metrics have on bottom line revenue can’t be understated. These are customers that were already paying for a service – that had already gone through a decision-making process, chosen one insurer, and were so dismayed with some aspect of their service that they chose to begin this entire search process again.
But there’s a simple…
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…
It’s taken a year for me to feel confident enough to even chime in, on a high level, about the products we’ve created, and the platforms we utilize. I can dabble in conversation about chatbots and Microsoft’s Cognitive Services. I understand now, more or less, what ‘the cloud’ is and its benefits. But, this is why teamwork makes the dream work, you know. My colleagues can build you a solution to any business challenge. Anything. You’ve got a problem, they’ll solve it.
But, now it’s my turn. I am going to express why what they can do matters.
You’ve all heard of Machine Learning. We partnered with RetailWire to produce a Webinar on ML for Retail back in April and that’s where my understanding really began to take shape. In a nutshell, Machine Learning can be set-up and do in minutes and…
SQL Server’s AlwaysOn technology (available since SQL Server 2012) provides high-availability and disaster-recovery database functionality which largely supplants mirroring and log-shipping – in fact, mirroring is now deprecated. Exactly what functionality is available and how robust it is, varies by release (2012+), edition (Standard versus Enterprise) and the physical infrastructure devoted to it. AlwaysOn is fairly easy to set up (though it requires cooperation from both Windows Server and networking admins) and, relative to the required effort, provides exceptional durability for SQL Server databases. AlwaysOn is not a complete OOTB durability solution and has significant gaps – e.g. it does not maintain SQL Server logins and roles synchronized across multiple servers – but it is an excellent start for the needs it caters to.
This post assumes the reader has at least a basic familiarity with SQL Server backups, as well…
When the Health Insurance Exchange (HIX) network went online in late 2013, the industry was challenged with reconciling new subscribers to their related premium payments and subsidies. Health plans painstakingly assembled Excel eligibility extracts to invoice their Federally Facilitated Marketplace (FFM) or State-based Exchange (SBE) for tax credit reimbursement. However, by the start of 2016, the FFM became the system of record for eligibility, and issuers were required to accept a new variant of EDI representing premium payments.
Traditionally, the 820-Payment Order / Remittance Advice transaction (005010X218) has been transmitted from payroll agencies and government healthcare organizations to insurers in order to provide summary or subscriber-level information regarding premium payments. With the advent of ACA exchanges, enough variations surfaced in this traditional handshake that a new version of the 820 was required. The HIX 820 (005010X306) removes structures unnecessary for exchange reporting, and adds tracking segments for the unique aspects of these plans, such as…
Let’s say the Finance Department of a clothing retailer has some great reports that let them see all the sales across the United States; so great, in fact, that they want to share them with all Regional Managers so they can communicate about the hot spots in their region. The problem is the Regional Managers aren’t permitted to see data outside their region, and giving them access to these reports would allow them to filter to any region they wanted. We could create separate Datasets and reports filtered to the region for the manager that is given access to them, but that would be time-consuming, and a nightmare to maintain. Luckily, Power BI provides the ability to implement Row-Level Security (RLS).
So, what is RLS? Simply put, it controls a user’s access to each individual row of the Dataset. In…
The Microsoft Office Store contains a growing library of custom Power BI visualizations developed by Microsoft and the community. While Power BI offers built-in visualizations, custom visuals can be downloaded for free and are used to enhance the way you display your data within reports and dashboards. Tallan has now taken its Power BI expertise to the next level by contributing our very own custom visual. Introducing the ‘Calendar by Tallan’ Power BI Custom Visual!
When associating dates with data, the first real-world visual that comes to mind is a standard 12-month calendar. While other custom calendar visuals exist in the Office store, the offerings did not portray the dates in this familiar manner or display the range of data desired. Tallan’s Calendar visual enables you to view the aggregation of data across a range of dates in a standard calendar…
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…