Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Politics : Formerly About Advanced Micro Devices -- Ignore unavailable to you. Want to Upgrade?

To: bentway who wrote (748261)	10/21/2013 2:10:56 AM
From: i-node	1 Recommendation Recommended By Brumar89 Respond to of 1571785

No, we're not. The standard protocols for communicating with insurers are not complex for anyone who has worked with them. I've coded the 837 and 835, both of which are more complex than these transfers, and you can do a decent implementation with a few c++ classes totaling less than 1000 lines for both. Demographics only require half that or less. Probably took a week or ten days to get that working. There was a good deal of JS in the front end and someone had to write the API, which is all JSON I believe. So it comes down to the "data hub" connecting with four legacy databases, only one of which should be a complex interaction (IRS). And the consolidated billing system, which would have been complex, just because of the numerous types of adjustment and similar transactions. I don't know what types of databases they are, but one has to presume that even the IRS database isn't that bad, given that IRS routinely makes changes (like every single year) and manages to get them done on time. Of course, we don't know whether they even have the consolidated billing system running at this point -- I would guess not. It is shocking they even did this in the design. Just plain dumb. At any rate, you're not talking about millions of lines of complex code.