An EDI software’s ability to identify and respond to invalid X12 HIPAA EDI transactions is a major contributor to the effectiveness of EDI dependent organizations. Many healthcare companies appoint a business unit as stewards of the tens of thousands of transactions that are transmitted between payers, providers, and trading partners providing auxiliary services. These business units are often hard-pressed to respond to the quantity of incorrect claims, enrollments and payments received within their current EDI solutions or products.
The T-Connect EDI Management Suite is Tallan’s healthcare EDI product, providing actionable insight, alerting, and painless mechanisms to respond to invalid X12 EDI transactions flowing in and out of the organization. The following is a brief introduction into some of these capabilities.
The EDI solution consists of several components working in unison to introduce, augment or replace an EDI processing system.
· The T-Connect Management Portal,…
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…
The X12 HIPAA transaction set is used across the healthcare industry to transmit claim, enrollment and payment information. Given the importance and ubiquity of these EDI files, you might assume that translating them from ANSI to a relational database format would be well-supported with a range of options.
In practice, a task as common as parsing a claim or encounter and storing it in a database can quickly escalate into a significant problem.
One solution we’ve seen involves archiving a snapshot of the EDI file using filestream storage. This can satisfy some retention requirements, but provides little in terms of fine-grained tracking or analytic capabilities.
A more complete approach is to parse the X12 file into its discrete elements and store them in a relational database. The ideal solution captures the full extent of the EDI transactions while also applying a reasonable leveling of flattening to keep in the number of table joins under control.
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…
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.
The following write-up will go through how to setup a connection to the Salesforce SOAP API using the Force.com Enterprise WSDL along with a custom connection pool wrapper I have written. I have used the repository pattern and object pool pattern to design a connection and connection pool for querying, saving, and deleting data from Salesforce through this SOAP API.
The connection pool code can be downloaded at the following github link.
The code from the link above enables you to query against any out of the box object or property. To hook into your custom Salesforce environment objects and properties you will need to update the Web Reference in the salesforce.connection project as outlined here. Also do not forget to modify the wsdl before updating the Web Reference because of the known bug with the wsdl generated from Salesforce.
Once you have…
I recently ran into an issue while working on a project dealing with an external, rate limited, REST API. We wanted to perform an action on several thousand local objects which required hitting this external service and getting back a response. Running in an iterative pattern wasn’t an option for us because it would take too long, and guessing the number to try per minute wasn’t an option either because we might incur extra charges from the provider of the external API. The solution was to create a rate limited ThreadPool in our C# application to perform the requests, and a BlockingCollection to store the responses.
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…
Braintree Auth is a new feature of Braintree that allows customers to link their personal Braintree accounts to a company’s platform. This technology allows the company to do all the heavy lifting by reading transactions and processing payments on the customer’s behalf. The process works similar to the way customers can sign in on other sites using their social media credentials.
Tallan is the first company to ever set up the Braintree Auth feature. We found a need for it on the SmartRaiser platform. Before we used Braintree Auth, customers were required to get their funds from SmartRaiser directly and the process could take several months to allow all payments to settle. With Braintree Auth, customers can access transactional information much faster and receive payments in as little as two business days.
Braintree has created a simple API to get started with…
WCF offers a lot of very powerful configuration and extensibility options – sometimes it becomes a bit dizzying.
I recently had a requirement to design a WCF service that could potentially consume many system resources (particularly, RAM) in some client scenarios. Any single call will be manageable, and concurrent calls would be manageable in some environments (but not others – the service is required to be able to process large files in a single call, but can only handle so much before running out of memory). Obviously, it would be good to find ways to split up calls to the service or for the client to sequence them, but WCF offers a very simple configuration attribute to specify that the service should run as a Singleton, processing only one call at a time:
Problem solved, right? Now what if a particular environment…