QNXT Custom Database

Warning: this post is not for the faint of heart. I will be discussing the customization of QNXT.


There are two types of customization that you can do with QNXT: configuration and custom coding. Configuration is a business process. You configure QNXT, by defining your business rules using the configuration functionality built in to QNXT. Some common configurations health plans apply in QNXT are the business rules around adjudicating claims, member eligibility verification, and authorizations. There are many business processes that you can configure using the native, or out of the box, functionality provided by QNXT.

Custom coding is a development process. There are two types of custom code development: supported and unsupported. I’m going to cover the differences between supported and unsupported code in another post. 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 allows for several points of integration. The ones we use are: the QNXT SDK (which I will cover in a separate post), 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. And 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.

TriZetto Hosting

What I’ve described so far is true of all QNXT installations. These next few paragraphs speak to the specifics of the QNXT Custom Database if you are a hosting customer. Each QNXT environment hosts a QNXT Custom and Stage database. If you have regions that have several environments this likely means that a single SQL Server instance at TriZetto hosts several Custom and Stage databases. So for example, in a single database instance, you may have development, unit test, training and configuration version of the Custom and Stage database. So eight databases in total. This creates an interesting custom code promotion problem. I think a typical scenario that most of us are used to when promoting a change from development, to unit test, to model office and production, you expect the database names in each of these environments to be the same. With the QNXT Custom Database at TriZetto Hosting this is not the case. You promote from Custom_Dev, to Custom_UT, to Custom_PPMO, and Custom_Prod.

There are a couple of solutions to this problem. Trizetto supports a ticket-based promotion process that will support these name changes as you promote up. So in this example, a customer may choose to setup a promotion process where they deliver custom code to the Custom_Dev database, and Trizetto manages the promotion of these changes going forward. This promotion process is custom tailored to customer needs. In our case, we chose our first promotion group to be PPMO. This means we manage the delivery of code to Custom_Dev, Custom_UT and Custom_PPMO, which puts more of this burden on us. We chose to do this because we realized a time savings during our implementation effort by opening fewer tickets. Instead of putting in a ticket (which may have a 24 to 48 hour turnaround depending on the change) to promote to Custom_Dev, we delivered the code there ourselves, an didn’t engage the ticketing system until we needed to deploy to Custom_PPMO. By this time, the custom code had gone through development, quality assurance and user acceptance testing.

If you are a hosting customer, you’ll likely be executing code in the QNXT Custom Database using a job scheduler and the TriZetto Hosted Batch Architecture (also known as the HBA, more on this in another post) which has Common System Properties that allow you to connect to the QNXT Custom Database.