Over the past several years, there has been a lack of clarity about Microsoft’s integration roadmap. Various integration tools have been offered, rebranded and renamed, and ultimately retired. With a lack of a published roadmap, it is hard to make an informed investment into an integration platform that needs to meet today’s needs and still be relevant into the future.
Since 2000, BizTalk has been around to meet critical on-premises integration needs. Many customers have implemented complex business-critical solutions based upon BizTalk. With the migration to the cloud and the advent of Integration Platforms as a Service (iPaaS) offerings, there have been concerns about the future of BizTalk and its role in Microsoft’s integration strategy.
A recent announcement by Microsoft’s Jon Fancey, the Azure Integration Services PM Lead, attempts to clear up some concerns about Microsoft’s integration roadmap and lays the foundation for what…
TriZetto QNXT is an end-to-end solution for health plan administration across multiple lines of business. QNXT uses a Microsoft BizTalk Server application called QNXT Connect to intake EDI and translate it into XML for processing; however, transforming an EDI file expands the size significantly. Large files can create a bottleneck causing BizTalk to slow or halt processing. For instance, a 10 MB EDI file can expand to 100 MB after BizTalk translates it into XML. For redundancy, BizTalk also stores that large message repeatedly within BizTalk Server’s database.
There are a few options to resolve performance issues encountered within BizTalk and QNXT system:
Scaling – Upgrading the system by adding additional servers (scaling out) or upgrading existing servers (scaling up). This may solve the problem temporarily but will quickly hit a period of diminished returns as the sheer size of the…
TriZetto QNXT is a longstanding leader in Healthcare administration platforms, supporting many lines of business including Medicare and Medicaid. An important function of QNXT is its strength in claim pricing, member administration and billing management. However, the provided QNXT toolset lacks flexibility in adapting to new processing requirements. For example, it would be difficult to perform member lookup and replacement prior to processing through QNXT’s modules.
Understanding the Workflow
QNXT utilizes Microsoft BizTalk Server to intake EDI X12 837 claims and X12 834 enrollments that are utilized in its various modules. 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. The XML is then sent into QNXT where it travels through QNXT’s built-in agents and modules.
However, it is often the case that custom logic is necessary to…
Each day health plan administrators look forward to the challenge of loading 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 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…
The Electronic Data Interchange (EDI) consists of a file in a specific format that represents data exchanged in a transaction from supply chain to healthcare. EDI 835 Claim Payment transaction provides payments information in reference to claims in EDI 837 Healthcare Claim format. The details include transactions such as charges, deductible, copay, payers, payee, etc. The information is stored a hierarchical structure. The standard of EDI format is well defined and the complexity can be very overwhelming. Additionally, we do not want this high degree of detail slowing our processing time.
One of the problems that enterprise systems face with EDI is file size. A single EDI 835 may contain multiple claim records and the quantity of claims in a single file can make it very difficult to process the file. Systems are often bogged down when dealing with a very…
835 and 837 EDI transactions have transformed the adjudication cycle for providers and health plans over the last two decades, but challenges remain in reconciling payments with claims. Recently, we’ve broken down the requirements for SNIP 3 claim balancing. Today we’ll focus on the 835 Claim Payment/Remittance Advice. Health plans submit 835s to providers (or their intermediaries) to explain which claims are being paid, and any reductions to the submitted amount and the reasoning for the adjustment. This is an important function – a significant pain point experienced by providers is the reconciliation of their income against claims submitted.
Before this valuable information can be loaded in practice management software, the 835 should pass validation checks. Common issues affecting 835s are balancing errors between the header and detail payment amounts. Imbalanced 835s lower the quality of reporting and can lead to billing…
BizTalk360 is a browser-based monitoring application for Microsoft’s BizTalk integration platform. The out-of-the-box monitoring functionality can be difficult to navigate both for new users and experienced admins, and is complex and time consuming to set up for multiple users with varying access rights. BizTalk360 combines the Admin Console and Event Log, with some added analytical and notification functionality, to create an easy to navigate operational tool.
In this overview of basic BizTalk360 setup, I will assume you have a BizTalk application already deployed that contains at least one receive port and send port. Although there is a huge amount of configuration and monitoring that can be done through BizTalk360, this article will focus on initial configuration and simple environment health monitoring.
One of the great new additions of the recently released Feature Pack 1 for Microsoft BizTalk 2016 is a REST API, which can be used to administer BizTalk Server. Longtime users of BizTalk may have experience with using ExplorerOM.dll or WMI based scripts to manage their BizTalk environment. The REST API introduced in Feature Pack 1 provides a more flexible alternative, including a Swagger definition providing rapid implementation of an application to consume the API. In this post, I will walk through the process of installing the API as well as using Swagger to generate a C# client and demonstrating a simple command.
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 EDI data are constant concerns for health plan payers.
Tallan’s T-Connect EDI Management Platform is an optimized integration solution founded on three core design principles:
An accessible 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 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…
On the provider side of healthcare integration, HL7 (particularly v2) is a critical message type to understand. While it is standardized and heavily used by various EHRs/EMRs, it’s used in slightly different ways. There are efforts to further standardize and normalize its use across the board (such as with v3/FHIR), many EHRs and EMRs continue to use 2.x messages. Common HL7 messages include admissions/transfer/discharge (ADT), scheduling (SIU), lab orders and results (ORU, ORM), and medical reports (MDM). Choosing the right platform can be challenging.
Some of the challenges of HL7 2.x messages include:
The ability to add non-standard custom segments or additional data anywhere in the message (whether they are completely custom “Z Segments” or other segments that aren’t typically part of the message, such as IN1 segments in an ADT message to include additional insurance information).
A myriad of parsing and manipulation libraries…