MIG NCCI Reporting System
Functional Specification
The purpose of this document is to explain the features and capabilities of a new system for reporting claims to Meadowbrook Insurance Group (MIG) to comply with the NCCI Data Call Guidelines. This system is implemented by the Blue Diamond Backend Systems (BDBS).
· Implement a fully automated system that requires the least amount of human interaction necessary.
· Fully report all account activity, including payments and reversals.
· Design a general enough system to reuse components in other state reporting applications like Texas, California and Florida.
Winnie-the-Pooh is a system administrator who oversees transaction submissions to MIG for the NCCI data call. Fortunately for him, the system is completely automated. He can spend his time collecting honey and playing with his friends like he wants, not drudging through state reporting files. That makes a sad bear.
Every 3 months, Pooh receives an email from the system telling him that a new Initial Submission File has been generated and is ready to send to MIG. This file, so says the email, is for the quarter that ended 2 months ago. Pooh figures that if the sponsor hasn’t paid for the transactions in 2 months, then he should report nonpayment and give the transaction a 0 payment amount.
The email Pooh Bear gets begins like this:
“The file FILE_NAME has been created for the initial submission of transactions for QN of 20NN. This file is waiting in the pickup queue to be sent out to MIG. Below is a detailed list of the included transactions:”
Afterwards, there is a line for every transaction put in the file. Pooh generally ignores all of these lines, but they are good to keep around…just in case. Here is a list of all the stuff on the lines:
· Group #
· Patient Name
· RX #
· Drug Name
· Amount Billed
· Amount Paid
Every Monday when Pooh comes into the office, he will have a new email from the system telling him about a new file generated the day before. This file shows Pooh a list of all transactions that were updated last week but had already been reported to MIG. These transactions have to be resent to MIG because they are now out of date.
Pooh really doesn’t care what the email says. He’s still thinking about his cozy bed in his warm tree in the Hundred Acre Wood. Regardless, he promptly deletes the email after scouring through it.
But before he deleted it, he saw all of this information for each transaction:
· Group #
· Patient Name
· RX #
· Drug Name
· Amount Billed
· Amount Paid
· Submission Type (Update or Cancel)
The submission type is particularly important because it explains if someone updated the payment information on the transaction or if the transaction was reversed by the pharmacy.
One thing the email does not have is exactly why the transaction was submitted. Was a payment added? Was one revoked? Was a credit note applied? This email doesn’t say. But that’s ok, because if Pooh wants to know more he can always go look at the transaction log in the BDBE.
Even though Pooh doesn’t care about a particular transaction’s long and rocky history through the MIG reporting workflow process, that doesn’t mean that no one does. Every now and then someone, probably Rabbit, might want to see the history of a particular transaction.
Well, Rabbit is in luck, because if he looks up any transaction that has been reported he will find a list of everything that has happened under the transaction log. What are all of the things that might have happened? Well, here’s a list:
· Marked for update resubmission to report zone MG because of applied payment
· Marked for update resubmission to report zone MG because of revoked payment
· Marked for update resubmission to report zone MG because of applied reversal
· Marked for update resubmission to report zone MG because of revoked reversal
· Marked for cancel resubmission to report zone MG because a reversal came in from EHO
We’ve talked about Pooh getting emails when new files get made, but what about actually sending the file off to MIG? Pooh doesn’t want to do that himself. Can you imagine a bear working a FTP client?
Once again, the system takes care of it. Every night, when Pooh is having nightmares about being chased by bees, the system looks for any files that haven’t been sent and tries to send them off to MIG.
When Pooh comes in the morning, he will have an email if there were any files to send off. If there are no files, then there will be no email. Fine by me thinks Pooh. The less email the better.
But if there are files, then we’ll have to see if they actually got sent off successfully. Maybe they did. Maybe they didn’t. So the email will have the following bits concerning each file it’s trying to send off:
· The file name
· The date the file was created
· Did the file get sent successfully? (SUCCESS or FAIL)
· If it failed, what kind of message did the remote server give back?
Pooh surely doesn’t keep this email around. There is no point in it because Pooh can always go view the submission log on the BDBE if he needs to later on. But if Pooh gets a failed messaged back a few days in a row. He should probably call someone because something’s not right!
Sometimes Pooh has to explain to people what did and what didn’t happen. There’s always a troublemaker that wants to blame Pooh. So Pooh has to know what happened, for his own sake.
The File Submission Log is just the thing for Pooh to keep a clear picture of the activity that has been going on in the reporting world. Accessibly from the BDBE, this log shows each attempted file submission to MIG. It’s sorted by submission date and has the following information:
· Date of submission
· File name
· Date file was first created
· Submission status (SUCCESS or FAIL)
· Server Message. What did the server say if it failed?
Things do not always go as planned. Sometimes NCCI rejects a particular transaction and it has to be resubmitted. It is always a data error. The data has to be fixed before another submission can occur. When a rejection occurs, Pooh gets an email with the rejection, the transaction id and the group number/claim reference number. Pooh can log in to the terminal system can fix the claim data.
That night the updated claim data will be resynced to the backend system. Pooh can click on a button in the backend to mark for resubmission. That night the claim will be resent.
Pooh keeps the following diagram in his desk to remind him of how a transaction gets reported, when it gets reported and how it gets reported. It would sure be embarrassing if someone asked him about this and he forgot it!