Tallan's Blog

Tallan’s Experts Share Their Knowledge on Technology, Trends and Solutions to Business Challenges

Category Archive for "T-Connect"

SNIP 6 – Line of Service or Product

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.
Type 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…

SNIP 4 – EDI Intersegment Situational Rules

WEDI SNIP Types define sets of rules for validating EDI transactions such as 837 claims, 834 enrollments or 835 Remittance Advice.
Previously, we’ve blogged about:

SNIP 1 & 2 Integrity and Requirement Testing
SNIP 3 Claim Balancing
SNIP 3 Remittance Advice Balancing
SNIP 5 External Code Set Testing

This article focus on SNIP 4, which test situational rules spanning separate loops, segments, or elements. What differentiates these rules from Type 2 is that the situational tests span distinct segments, while Type 2 is considered intrasegment testing. Intrasegment tests validate the presence of elements within the same segment based on syntax rules.
Type 4
SNIP 4 situational rules break into two categories. Both categories consist of a condition statement, then a data item (loop, segment, or element) which should (or should not) be present based on the rule evaluation.
Category 1
The first category of situational rules specifies that sending the specified data item is up…

SNIP 5 – HIPAA External Code Set Testing

The HIPAA X12 EDI specification allows for the inclusion of code values that may be pertinent to the transaction set, such as a claim or encounter. These code values can represent a data point as widespread as a postal or zip code, or as complex as diagnosis and procedure codes.
WEDI describes seven types of validation, referred to as SNIP 1-7, as covered in some of our previous blog posts on SNIP 3 Balancing of Claims and Payments. SNIP 5 – HIPAA External Code Set Testing is the validation of code values against the external code sets they represent.
SNIP 5
As previously stated, SNIP 5 validates that code value exists within an external code list. For example, if a postal (zip) code is present in a subscriber’s address, then it should align with an actual postal code in as determined by the USPS, the…

Rapid EDI Trading Partner Onboarding with T-Connect

HIPAA X12 EDI transmission between the many entities in the HealthCare industry is performed using files conforming to ANSI X12 specifications. These Claim, Premium Payment and Remittance Advice EDI files may originate from payers, providers, clearinghouses, or third party administrators (TPAs). One prevalent hurdle in sending or receiving these EDI transactions is the often complex onboarding process of new trading partners.
HIPAA EDI files in X12 format may typically look similar to the sample below.

Submitting Workers Compensation Claims as 837s

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…

CAQH CORE Certification Tips

CAQH CORE certification demonstrates that health plans, clearinghouses and software vendors meet federally mandated operating rules when exchanging HIPAA EDI transactions. Internally for organizations, the certification process provides value by exercising a broad variety of test cases. Last but not least, CORE specifies the message envelope details for exchanging EDI over two types of HTTP endpoints, reducing the implementation times that custom message formats can incur.
The CAQH website is the complete resource for understanding the types and variations of CORE certification. In this article, we’ll take a complementary approach. Rather than attempt to summarize the full spectrum of options, we’ll focus on a single use case in order to highlight key information and technical challenges. Tallan’s T-Connect Eligibility Module places us in the software vendor category. Our EDI management solution enables health plans to act as an information source to respond to 270 Eligibility requests with a…

Tracking and Fixing Encounters, Enrollments and other EDI with T-Connect

There are several ways to intake, parse and route encounters, enrollments, payments and other HIPAA X12 EDI files. However, there are often deficiencies that become quickly apparent, as not many systems provide an adequate level of insight into the status of the in-flight files, nor do they have the tools needed to respond to issues once they arise.

Processing Large EDI Files in QNXT using T-Connect

The Challenge
TriZetto QNXT is an end-to-end solution for health plan administration across multiple lines of business. QNXT uses a Microsoft BizTalk Server application called QNXT Connect to intake EDI and translate it into XML for processing; however, transforming an EDI file expands the size significantly. Large files can create a bottleneck causing BizTalk to slow or halt processing.  For instance, a 10 MB EDI file can expand to 100 MB after BizTalk translates it into XML.  For redundancy, BizTalk also stores that large message repeatedly within BizTalk Server’s database.
There are a few options to resolve performance issues encountered within BizTalk and QNXT system:

Scaling – Upgrading the system by adding additional servers (scaling out) or upgrading existing servers (scaling up). This may solve the problem temporarily but will quickly hit a period of diminished returns as the sheer size of the…

TriZetto QNXT – Preprocessing Limitations

TriZetto QNXT is a longstanding leader in Healthcare administration platforms, supporting many lines of business including Medicare and Medicaid.  An important function of QNXT is its strength in claim pricing, member administration and billing management.  However, the provided QNXT toolset lacks flexibility in adapting to new processing requirements.  For example, it would be difficult to perform member lookup and replacement prior to processing through QNXT’s modules.
Understanding the Workflow
QNXT utilizes Microsoft BizTalk Server to intake EDI X12 837 claims and X12 834 enrollments that are utilized in its various modules.  The files are translated from EDI to XML within BizTalk’s native EDI parsing pipeline component deployed as part of QNXT’s ‘QNXT Connect’ BizTalk Application.  The XML is then sent into QNXT where it travels through QNXT’s built-in agents and modules.

However, it is often the case that custom logic is necessary to…

TriZetto QNXT – EDI Reporting and Tracking

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…

\\\