TriZetto QNXT

What do you like best?

For EDI reporting and tracking, the QNXT database and the way it's structured makes it easy to effectively conduct research and provide resolutions for client issues with custom reporting. Reports generated from within the QNXT application. As well, the backend data can be used in conjunction with error logs which provides data downstream for the Executive Dashboard by developing a new MS Access Benefit Load and Tracking Database. As well, a great platform which makes it a straightforward process to effectively troubleshoot incidents errors in 837 and 835. The QNXT database integrates nicely when you write and run SQL queries on Oracle or SQL Server database table joins with QNXT.

What do you dislike?

QNXT is great at pricing claims, administering members, and managing billing. The issues are with having to adapt to new requirements in processing. For instance, it's difficult to do a member lookup and replace before processing. QNXT intakes 837 claims files and EDI 834 enrollment files using Microsoft BizTalk Server. 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. QNXT receives the XML where it is carried through it's modules. However, it is often the case that custom logic is necessary to ensure the success of the message within QNXT. This can be due to:

Enrichments or lookups necessary to the file, such as the previously mentioned need for a member lookup and replacement

Conditional routing based on success or failure of the file

Pre-validation to prevent a single failed record from causing failure of the entire transaction set

Typically there are two ways to allow for the application of custom logic within a QNXT implementation – applications deployed in BizTalk, or custom agents deployed in QNXT.

Developing BizTalk applications, while very robust and flexible, require an advanced skill set to employ effectively. Not only does a developer have to know BizTalk, but also have a high degree of knowledge of XML in order to properly ‘work' with the EDI. BizTalk does not supply out of the box APIs to ease the EDI development burden when working with healthcare data.

Looking back at the scenario of member lookups, a BizTalk application would have to be created that would perform member lookups and replacements. This however, would require knowledge of XPath navigation of the XML schemas used by BizTalk to update the member fields.

QNXT agents can be developed in C# .NET, and easily deployed using a QNXT provided deployment wizard. These agents can be positioned to execute prior to processing (Pre Agent) or post-processing (Post Agent). An executing agent has access to an XML representation of the EDI data received by QNXT, whether claims, enrollments or other data sets.

Using an agent negates the need for specialized BizTalk knowledge, however presents several limitations that have to be overcome:

XML: EDI is presented as XML within another XML wrapper containing file specific metadata injected by many layers of nesting and knowledge of XPath may present difficulty in developing an agent.

Testing: Testing custom pre and post agents requires either attaching a debugger to QNXT or careful interpretation of log entries within the QNXT process log browser.

Tracking: QNXT only surfaces the start and end of a custom agent's execution, with only basic record counts and a success/failure logged.

Maintenance: There is a wizard provided to deploy agents, however custom built agents may need frequent updates to ensure compatibility as new QNXT versions are deployed.

QNXT Pre and Post agents' custom steps do not have access to the full X12 EDI message and a robust EDI parser, validator, splitter among its API tools. This is helpful in allowing seamless editing and resubmission of problem claims or enrollments.

Preprocessing EDI files within an existing TriZetto QNXT implementation remains a challenge in some cases.

What problems are you solving with the product? What benefits have you realized?

Custom coding is a development process. There are two types of custom code development: supported and unsupported. Supported and unsupported code are both deployed to the QNXT Custom Database. Custom coding is not used to enhance the QNXT application itself. Put another way, the QNXT application is not something that can be modified under the QNXT license and support agreement. Custom coding is used to extend QNXT, or to allow for integration with QNXT. These customizations are applied outside of QNXT itself. Some common examples of custom code are extracts and interfaces to other line of business applications like Finance/Accounting, CRM and Case Management. QNXT also does a good job of allowing for several points of integration. The ones I've used are: the QNXT SDK and the QNXT Custom Database. The purpose of the QNXT Custom Database is to provide a layer of abstraction over the out of the box QNXT database called Plan Data. Changes that ordinarily could be applied to Plan Data, by way of new stored procedures, views, and other database objects, are applied to this Custom database instead. This way the Plan Data database remains unchanged, with all customer customizations are one place, the Custom Database. The QNXT Custom Database hosts all custom database code, as well as any data that supports these customizations. There is also a QNXT Stage Database. This database is also used for customization. The difference is the Stage database is permanent in structure, but temporary in storage. It is a temp database. If you have an extract for example, that requires some pre-processing or post-processing, you can temporarily host your interim-state data in Stage.