TriZetto’s QNXT is a widely adopted platform for claim processing and membership administration. QNXT relies on the Microsoft stack, particularly BizTalk, .Net and SQL Server, to process and store EDI messages.
These technologies give developers many tools for customizing and tracking HIPAA transactions, but the complexity of implementing business rules and lifecycle reporting on Electronic Data Interchange (EDI) data is a constant concern for many health plan payers.
- An accessible developer API. One of the most common challenges our partners face is implementing business logic on EDI. T-Connect loads all HIPAA transactions into a fully compliant hierarchical data structure that can be manipulated with familiar tools such as Visual Studio and .Net.
- Full EDI database persistence. Going from EDI to a relational database is a frequent business need, but capturing the full set of fields present in an 837 alone represents a massive development undertaking. T-Connect enables persistence of all data fields in each HIPAA transaction out-of-the-box.
- Speed. Anyone who has managed EDI processes has likely watched their middleware platform slow to a crawl on relatively modest file loads. While this can occur for many reasons, a fundamental issue is that these middleware platforms are designed to handle an enormous variety of messaging formats and come with the cost of generalization. T-Connect EDI Software was designed from the ground up to parse and store EDI. On Caliber’s website, we’ve posted a video showing our capability to load 500,000 enrollment records from into a database in under 7 minutes.
In this blog post, we’ll focus on the ways these unique capabilities enhance and extended QNXT integration scenarios. Pre-processing with the T-Connect SDK API In a few cases, the claims, enrollments and other transactions received from trading partners may be loaded into QNXT without modifications. More commonly though, some type of enrichment or transformation is required. TriZetto provides a mechanism for this: custom agents, which are .Net-based libraries implementing a QNXT-derived interface. After developing these DLLs and registering them in the PlanIntegration database, developers receive an XML copy of the message as it flows into QNXT, which can be modified and resubmitted before persistence in PlanData.
While functional, this approach comes with pitfalls. Manipulating this XML makes for error-prone and difficult-to-maintain code. Also, these custom agents typically run on distributed execution units, making real-time debugging of these pre-processes extremely difficult.
When deployed in an intake process prior to QNXT submission, the T-Connect SDK API for developers can be used to rapidly implement business logic in a natural development environment. Loading a file into the object model can be done in two simple lines of code:
The T-Connect API is patterned after XDocument, which provides clear navigation and modification options for tree structures. Here’s a simple example of an edit to an 834 enrollment, which removes a name suffix from the NM107 element and appends the suffix to the last name:
We find the T-Connect API well-suited to implementing complex business requirements on EDI messages as they flow through intake processes.
Lifecycle Tracking and Database Persistence
We encourage our partners to persist their EDI messages to a database, in many cases both on receipt and after applying transformations. Without this step, it becomes very hard to provide reconciliation reports to the business, who will need to account for each claim, enrollment or payment received and submitted to QNXT.
It’s not uncommon for EDI messages to fail before QNXT has a chance to record them in PlanData. Validation failures will be caught and suspended in the QNXT Connect BizTalk application before the core QNXT processor has a chance to record these messages. By persisting the original transaction in the T-Connect database, it becomes possible to build reports accounting for fallout and other error conditions.
Saving an EDI file to the T-Connect database is simple:
Each HIPAA transaction is implemented as a fully normalized SQL Server database:
Caliber Health has developed a custom agent that enables the creation of fully-realized QNXT reconciliation reports. The T-Connect intake process stamps EDI transactions with a unique key on a specified level – this could be the 2300 claim level in an 837 transaction, for example. This identifier will travel with the claim in a user-defined segment, which is later accessed by the custom Post Agent and inserted into a crosswalk table mapped to the QNXT ProcessLogDetailID. With this combination of records, it becomes possible to trace a transaction from receipt to successful (or failed) intake into QNXT.
Improving EDI Intake Perfomance
QNXT Connect can bog down when loading large EDI files. We’ve seen significant performance and reliability gains when T-Connect is placed at the start of an intake process. With the ability to rapidly parse and persist massive transaction volumes, T-Connect can be used as a gating mechanism to split EDI submissions into smaller batches and release these transactions in measured intervals to allow for optimum intake.
With our ability to rapidly store claims, we can achieve real-time dashboard views with tools such as Microsoft’s Power BI:
More sample visualizations are available on our Partner Showcase site.
The T-Connect EDI Gateway offers a specialized toolkit for advanced HIPAA transaction management. Leveraging a familiar .Net API, complete database persistence model and a highly performant EDI parser can bring benefits to any organization required to process X12 transactions.
In this blog post we’ve focused on specific improvements T-Connect can make when integrating with Trizetto’s QNXT platform. In the next post in this series, we’ll highlight the value T-Connect can bring to supply chain management scenarios.
Visit Caliber Health’s EDI software comparison page to find the solution to meet your healthcare data processing needs.