Healthcare 5010 Conversion

Posted by on November 11, 2011 in Health Care, Health Care Interfaces, Rant | 0 comments

Healthcare 5010 Conversion

The deadline for 5010 conversion is quickly approaching, and I must say that this should not be that big of a deal. Anyone that processes a 5010 transaction should simply have to update their systems to accommodate for the new format. However, it is causing alot more issues than I think people realize, and there are two reasons that stick out in my mind.

Reason 1: Software vendors are slow.
Software vendors are notoriously slow for putting out updates. Why? Because they’re more than likely understaffed to keep costs down, and don’t have the time to develop. They don’t have the time to fully test either, which causes issues down the line. Also, if they’re not getting paid anything extra for the update, say it’s a feature that’s part of another service they offer, or it falls under general maintenance that people pay for the software, they will be less likely to put any priority behind the project because it won’t bring in any additional revenue. Nevermind the fact that the users really need it to perform their tasks.

Reason 2: Systems are old.
Software costs a good bit of money for a good system. Therefore, companies need to get as many years as possible of use out of it before upgrading or buying a different piece of software. Old systems are less flexible and less likely to be able to be patched in any good manner. Software companies may not even support old systems making it impossible or very costly to put the 5010 updates in place. Companies that force users to upgrade solve that issue, but clients may be reluctant to pay for the upgrade. Even if the client gets the update, putting new logic into an established system can lead to glitches that are unforeseen.

Some examples I’ve seen:

5010 now requires that NDC codes be sent for every vaccine on a claim. Medicaid’s system can not handle more than 1 NDC code per claim. Responsibility and cost fall on the claim submitter to adjust their claim submission in order to get paid.

REF segments in the ansi x12 835 file are randomly denied due to invalid content by Keystone East. These fields are used at the submitter’s discretion and can contain any text they want, yet claims are denied because of what the insurance company “thinks” the submitter should be using there, not what the standards say.

Standards exist, and one of my biggest pet peeves that you’ve heard me rant about before is the fact that they are not followed, even though they are presented like they are followed. All of this adds bloated expenses to the Healthcare industry.

If you enjoyed this post, please consider leaving a comment or subscribing to the RSS feed to have future articles delivered to your feed reader.

Leave a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>