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.
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 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…
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…
X12 Studio provides validation capabilities that can be used to validate claims, enrollments, and other HIPAA X12 EDI file types. X12 Studio can be used to test those files by reading, validating, and producing an X12 999 Acknowledgement (ACK). The 5010 999 ACK replaced the previous version – 4010 997 ACK. The 999 ACK informs the submitter that the EDI submitted is validated according to the receiver’s implementation guide. This validation includes the results describing the quality of the functional group’s syntax. Sometimes this validation is referred to as WEDI SNIP level edits 1 and 2.
Steps to Generate the 999 ACK
To start, download X12 Studio and install the application:
Launch the application and open an existing 837I, 837P, 834, or any of the HIPAA X12 EDI files:
Click on the Generate ACK 999 icon in the top menu:
View the Output tab at…
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…
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…