TriZetto QNXT – EDI Reporting and Tracking
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 synonymous with SNIP Types 1 & 2. After validation, a 999 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.
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 a solution designed to integrate with existing infrastructure and track the flow of inbound and outbound EDI transactions.
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 a relational database, 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:
Maintenance of an adjudication platform is significantly simpler with an expanded set of tools to manage the gaps between receiving EDI and processing payments.