Resolve Document Upload Error

 

The fax (or individual attachment split out from a multi-page fax) contains no identifiable barcode. This usually happens when a barcode is not found on the very first page of a fax. Here are some examples:

 

A three-page fax with no barcodes on it whatsoever. In this case, a three-page attachment will be put into the queue for identification.

 

A 10-page fax with barcodes on pages 4 and 8. In this case, pages 1-3 will be grouped together as an error (there is no code to identify them) and placed in the queue, pages 4-7 and 8-10 would become attachments and be processed normally.

 

 

The fax (or individual attachment split out from a multi-page fax) contains a barcode, but it is not an athenaOne barcode. This may happen if a page in the fax contains a barcode, but it is not a header page. This may cause confusing groupings of attachments.

 

For example: A 10-page fax has a header page on pages 1, 5, and 8; however, page 3 has a barcode on it. The fax will be split up into four attachments: pages 1-2, 3-4, 5-7, and 8-10. The attachments starting with pages 1, 5, and 8 will be processed normally. Note that the attachment starting with page 1 will be created, but without pages 3 and 4!. The attachment consisting of pages 3-4 will be placed in the error queue.

 

 

This error is used when a fax has been received, has the needed barcodes, and has been split into multiple attachments, but an error is encountered with an individual attachment (and that error is not NOCODE or BADCODE).

 

The most common reason that an attachment would be marked as a SPLITERROR is if we found a barcode, but it doesn't identify anything. Here are some examples:

 

1) Suppose there is a one page fax that is just a header page. The barcode is found, and it is a valid code, so we try to attach the rest of the fax to the claim. But the rest of the fax is missing. We can't attach a null document to the claim, so we put this in the error queue as a SPLITERROR, since we were trying to "split" the header page from the attachment it was identifying, and there was nothing on the other side of the split.

 

2) Suppose there is a three-page fax with header pages on 1 and 3. The first attachment (pages 1-2) would get processed normally, and the third page would get handled as described above.

 

3) Suppose there is a 10-page fax with header pages on 1, 5, and 7, but Page 8 contains a non-athenaOne barcode. Attachments for pages 1-4 and 5-6 would be processed, page 7 would become a SPLITERROR (as described above) and pages 8-10 would be placed in the error queue as BADCODE.

 

4) Suppose a fax data was somehow corrupted during the split process, such that it became unreadable. This might also produce a SPLITERROR (this is very, very rare).

 

 

This error is used when a fax (or individual attachment split out from a multi-page fax) has a barcode we've already processed (or the attachment is already on the claim).

 

The attachment is placed in the queue, and can either be deleted, or chosen to replace the current attachment.

 

 

The fax (or individual attachment split out from a multi-page fax) contains a barcode that identifies a claim attachment that doesn't exist (rare for a faxed attachment).

 

 

This rare case happens when an incoming fax contains corrupt data (perhaps a transmission error, or some other rare error). The means the fax is unreadable and will have to be sent again.

 

 

Refer to filedrop interface specifications for information on what constitutes a valid file that athenahealth accepts. This section details the errors that may occurs when using the filedrop interface. If athenahealth picks up a file that does not meet specs, or encounters some other error, it will be placed in the queue.

 

FILEFORMAT:

We currently require that all files either be a .pdf or a .tiff. If the file is not either one of these types (or, if the .tiff is in the wrong format and cannot be converted to .pdf), this error will occur. You will have to recreate the file and re-queue it for retrieval.

 

FILENAME:

We have strict conventions for file names. We use the filename information to determine where the file should be attached. If the name of the file does not meet specs, it will be placed in the error queue.

 

INVALIDDATE:

The filename encodes, among other things, the date of service for the claim with which the attachment should be associated. If you name the file with an invalid date (e.g., 20050231 — there is no February 31), the file will go into the error queue.

 

ATTACHMENTCLASSERROR:

Another piece of data encoded in the filename is the three-letter abbreviation for the type of attachment the file represents. If the abbreviation is not an accepted one, the file will be placed in the error queue.

 

NOTFOUND:

Based on the filename, we try to finding an empty claim attachment that matches that information. If none is found, the file is placed in the error queue. Note, that if we find a matching claim attachment, but it is already filled, the file will marked as NOTFOUND, since we did not find an empty slot to place this file in.

 

MULTIPLEFOUND:

It is possible to have more than one attachment of the same type, for the same date of service and patient. In this case, we might not know exactly where you wanted the attachment to go, since there are multiple claims to which we could attach the file. The file would then go into the error queue, where you could choose the proper claim. Note that this error can be avoided by activating Sequence Number Matching for the filedrop interface. Talk to your account rep for more details.