Tallan's Technology Blog

Tallan's Top Technologists Share Their Thoughts on Today's Technology Challenges

Category Archive for "T-Connect"

Splitting 835 Healthcare Claim Payment

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…

All-Payer Claims Database Submission – Common Data Layout and PACDR X12

As we strike out into 2018, the implementation of All-Payer Claims Databases (APCD) across states remains variable and dynamic. Massachusetts maintains a comprehensive implementation, aggregating data feeds from over 80 public and private payers.  Massachusetts has leveraged their APCD to create a state-specific risk adjustment model to meet the ACA provision which balances funds from healthier populations to higher risk pools. Late in 2016, Minnesota concluded a feasibility study which determined their APCD could significantly improve risk adjustment vs. the federal model.
On the other hand, West Virginia and Tennessee have put APCD development on hold. California payers optionally submit claims and encounters to a public benefit corporation. Legal, fiscal and political concerns guarantee a fluid situation for insurers.
This blog post is focused on the technical obstacles that health plans face in states requiring APCD submission. Since these databases have phased in over the last decade through both voluntary and legislated…

X12 EDI Databases for HIPAA Transactions

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.
The…

SNIP 3 835 Balancing

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. 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 errors and lost revenue.
WEDI describes up to seven levels of validation,…

Setting Verbose mode for a Boomi Process using Dynamic Process Property

Setting Verbose mode for a Boomi Process using a Dynamic Process Property
In most instances developers will have to accommodate certain reporting, notification and logging requirements of a given interface within the Dell Boomi AtomSphere platform.
Often times, the logging or emailing may need to be disabled for testing and/or faster iterative cycling through test cases and, of course, to not annoy the user community with email test messages.
The most straightforward way to accomplish or implement a verbose or Test Mode Boolean flag (as is very common in other platforms) is to create and enable a Dynamic Process Property and then assign its default value while allowing to reassign the same with extensions directly after deployment.

Using Dell Boomi Extensions

Dell Boomi provides the concept and implementation of extensions to allow developers and administrators to have distinct values for different environments without having to use multiple connectors of the same type.
As an example in a given scenario where a Dell Boomi Process uses a disk connector to read a file but the file location changes from environment to environment.
EG:
1. Test Server file folder location: C:\TEST\Inbound
2. QA Server file folder location: C:\QA\Inbound
3. Production Server file folder location: C:\PROD\Inbound

B2B Challenges in Healthcare

Tallan Partner

It’s no secret that paying for healthcare in the United States is extremely difficult to do. Payment systems for healthcare across the country are highly fragmented; many payers and providers use multiple formats for remittance. This creates challenges and frustration for patients, providers, and insurance companies, particularly at a time when there is increased pressure to reduce costs. Other industries use B2B automation processes in standard languages like EDI to standardize and automate payment systems; B2B challenges abound for the healthcare industry.
The B2B challenge in healthcare remittances
Thanks to the Affordable Care Act, there are now in motion some new initiatives related to healthcare payment reform – chief among them, the transition from fee-for-service to value-based care.  “The ramifications of this transition for payers are significant,” says John Tyler, Data Science Platform Manager at Premera Blue Cross. “Payers are going to…

Enhanced QNXT Integration – EDI Transformation and Tracking

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…

Considerations About HL7 Integration

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…

Why the Healthcare Industry is Utilizing EDI as the Standard in Managing Increased Enrollment and Regulation

Gabriel Gomez

Over the past few years, the healthcare industry has undergone a complete overhaul of how it processes information. This was brought about by a growing list of new and complicated regulations handed down by federal and state governments that stem from the Healthcare Insurance Portability and Accountability Act (HIPAA) and the Patient Protection and Affordable Care Act (ACA), designed to improve the efficiency and effectiveness of the industry. These regulations include standardization of the electronic transmission of Electronic Data Interchange (EDI), which also protect the security and privacy of electronically transmitted information provided by their patients.
These mandates created an immediate challenge to healthcare organizations, because it required the industry to take increased ownership and control of Electronic Health Records (EHR). In order to meet this demand quickly, healthcare providers scramble to leverage a variety of methods to manage their EDI…

\\\