TriZetto QNXT – EDI Reporting and Tracking

Each day health plan administrators look forward to the challenge of loading EDI 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 the plan’s EDI Software 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 EDI 837 transactions are well-formed. This level of validation is synonymous with SNIP Types 1 & 2. After validation, a 999 acknowledgement response file is generated and returned to the claim submitter.

Extended Validation – Many health plans running QNXT will perform a member and provider lookup at this stage. This involves joining the incoming patient information against PlanData eligibility and provider tables. Failures at this stage, as well as other types of extended validation such as claim balancing, result in a business level rejection, typically in the form of a 277-CA.

QNXT Connect –  An on-premise installation of QNXT requires a BizTalk application called QNXT Connect. QNXT Connect has two primary responsibilities:

  • Convert the EDI to Microsoft’s BizTalk XML format, with an envelope containing additional metadata.
  • Connect to the PlanIntegration database and initiate the load into PlanData.

Process Log Browser – Hopefully by the time you arrive at this stage, you’ll see more SUCCESS in process status than ERROR.

Process Log Browser
Process Log Browser

With these details in mind, some of the pitfalls to comprehensive reporting become clear:

  • Structural validation may result in the rejection of a subset of claims from the original file.
  • Additional claims may fall out due to failed member or provider lookups.
  • Some claims may suspend while loading in the BizTalk QNXT Connect application.

A snapshot of the claim lifecycle requires database tracking, configurable to the specific workflow a health plan employs. T-Connect is an EDI Gateway solution designed to integrate with existing infrastructure and track the flow of inbound and outbound EDI transactions.

EDI Lifecycle Tracking
EDI Lifecycle Tracking

By defining workflows in T-Connect, it’s possible to track each stage of enrollment and claim intake, with snapshots of the messages at each stage of the intake process.

This database persistence comes with additional benefits. Once inbound 837s are stored in EDI databases for HIPAA transactions, claims can be correlated with outbound 835 Remittance Advice and 999/277-CA acknowledgements to provide deeper insights into the full spectrum of payment processing.

Here’s a simple view of 837s, 835s, and 277-CA correlated:

Joining an 837 to an 835
Joining an 837 to an 835

Maintenance of an adjudication platform is significantly simpler with an expanded set of EDI tools to manage the gaps between receiving EDI and processing payments.

At Caliber Health, we’re always interested in discussing EDI management challenges. Contact out to us for a consultation to discuss how we can address these challenges within your current infrastructure.

Leave a Reply

Your email address will not be published. Required fields are marked *