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…
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.
In the last post, I wrote about the overall structure of 837P claim messages. 837I and 837D messages have similar structures, though with some differences – for example, the 837I has many more diagnosis code options, and the 837D has more specific nodes for tooth identification, etc. One important thing to note is that 837P, 837I, and 837D files are very similar, but not the same. It’s not enough to simply change the version numbers in the GS and ST segments and then try to process one the same as the other! If it were that easy, we wouldn’t need separate schemas for them in BizTalk!
BizTalk provides out of the box functionality to support these message types, with well developed functionality to translate the X12 EDI to XML and vice versa. The schema nodes also have friendly names, translating something like this:
Updated: part 2
Application integration is challenging in that it requires a wide breadth of knowledge: server and network architecture, object oriented programming and design patterns, messaging and communication patterns, workflow design, message translation, database design and programming, business rule processing, data validation and quality handling… the list goes on and on. On top of that, it’s important to be familiar with the data you’re working with from various sources and feeds to be able to effectively transform it.
EDI presents a whole host of challenges, and the 837 Professional, Institutional, and Dental transactions are among the most challenging to grapple with. This will be the first in a series covering a high level introduction and overview of the 837 Claim format in the BizTalk HIPAA EDI schemas. It is not quite going to the level of a competent EDI Analyst, but…