Greetings, I’ve worked with folks doing these against various different systems- so here goes a summary…
1. The actual process. There’s two basic types of payment posting – as for why you’d do one vs the other… no idea a. Typically the script starts off by creating some sort of batch then proceeds to enter in either… b. Claim summary – for each account enter in what you asked to be paid, and what you got back (fairly easy to spec out) c. Line item details –(may include summary info or totals are calculated) for each account, enter in each procedure that was performed, what you asked to be paid and what you were paid (Much more work to spec out) d. And then typically closes the batch and may do something with the file etc. 2. The File itself. The 835 is an X.12 document. Countless trees and electrons have lost their lives describing its structure. The entity sending you the 835 will be able to provide an often voluminous tome that describes it. You will need this! Thankfully most of the information contained herein will be irrelevant to the scripting task at hand. Basically an X.12 document is organized into Segments. Each Segment has an identifier and fields. The DataStation does a good job of parsing an 835 (or any other X.12 document). Each Segment will be a DataStation Record. You’re script will walk through the records, seeing what Segment it is on, and will do something based on the Segment it sees. The website has examples of how to do this. At a minimum you will care about CLP segments (CLP being the identifier). This segment has the claim summary details as well as the patient’s account number. If doing Line Item details, you will care about other segments in addition to the CLP - SVC which holds (procedure code, what you charge, what you got paid) CAS – this is the biggie it holds all the “denials” as well as the deductibles, etc. You will spend most of your time specking out what to do based on values contained within CAS statements. 3. The spec-ing out process. I cannot stress this enough – you could (and probably should) spend more time here than doing the actual scripting. The actual keying in of the data is really quite simple. I’ve seen A LOT of time wasted because of just jumping in and scripting and learning the workflow as you go. The most complex part is handling the different permutations for why things were denied and what needs to be done because of it. More than a few times I’ve worked with folks had been “just doing things” that really wasn’t what they should be –and didn’t know it until they thought about automating the process! If you don’t fully know the data entry process find someone who does – better yet, find 3 people who do, because they may give you conflicting information (seen that happen more than a few times too) 4. The scripting process. I’ve seen this handled two ways: a. Parse through the data and “flatten it” (easy to do with Claim level posting) – really can’t flatten too much with Line item – but can make it somewhat easier to navigate through then script in the “flattened data” b. Use “decision tree” that drives the data entry (easier than it sounds actually thanks to Rules). Here the script reacts to the value of D(“Segment”) for example - D(“Segment”)=”CLP” Goto – Save Patient (if its not the first) and the lookup the next patient (since CLP has the account number). D(“Segment”)=”SVC” – Enter Procedure info. Etc. By walking down the file it knows when it’s got a new patient (time to save the previous) etc. 5. Error and Exception handling – Best advice I can give here is to first focus on entering in “normal patients”. Don’t try to handle all different permutations / exceptions at first. Start off by building your script so that it kicks out all “exceptions”. It’s worth putting in some time to generate good “kickout reports” (I’ll come up with an example and post it this week). Put this script into production for awhile. A thought I hadn’t thought of until now would be to instead of adding handling exceptions to the original script – perhaps just script from the exception report (unsure if that would work due to batching etc. (thoughts?). Hope this is helpful! Regards, Thom Thom C. Blackwell Product Manager Boston Software Systems (866) 653-5105 ex 807 <http://www.bossoft.com/> www.bossoft.com <http://www.bostonworkstation.com/customer_center/special_events.aspx> Sign up for my weekly webinar! LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Erica Weichmann Sent: Tuesday, December 18, 2007 1:12 PM To: [email protected] Subject: [Talk] BSW 835 Processing I am new to Boston, have had some small successes so far and am about to tackle automating 835 posting...I have seen a few threads with info, any helpful tips/scripts/db layouts would be great! Thanks, Erica Weichmann Alexian Brothers Health System Special Projects COFIENIAIT NTIE:Ths -milmesae,inluin ay ttchens,isfo te ol ue f heinenedreipen(s ad aycotan onidntalan pivleedinoraton Ay nathriedreie, se dscosreorditrbuio i pohbied I yu reno te ntndd ecpint peae onac te enerbyrelye-ai ad esro al opesofth oigna mssge
