Paper UB92 Form to UB92 837 Process

The UB92 form is one of the most popular forms in the health care industry today. If filled out correctly, all the data on an average UB92 form can be extracted in just a few seconds.   

By using our Electronic Health Claim Processing techniques you save time and money. If you were wondering exactly what a paper to EDI solution entails, and what data is extracted from a UB92 claim, please review the rest of this page.

Below is a list of fields, which will give you an idea of what a processed UB92 form may include. Also included are various types of data integrity checks that may be employed when utilizing our electronic claim processing services.

Field 1. Servicing Provider - Intelligent data extract is used to parse out the data. A table can be used to populate this field based upon the provider phone number, which is usually supplied. When this field is not filled out, many providers request the claim be rejected and returned.

Field 2. Not named and usually unpopulated. - Every UB92 Form that is processed must be stamped with an easy to read number, which will differentiate the claim from every claim submitted in the future. These numbers also act as a great way to track claims once they have been processed. This number is applied via a bar-coded sticker which can be captured very easily and with 100 percent accuracy.

Some service bureaus stamp claims by using scanner imprinters during the scanning process. Unless the claims are sorted before scanning this can lead to lost claims. If a separate bar-coded label is applied to each claim before scanning, an instant inventory is created. This inventory allows for precise accounting of claims. If I stamped 2157 claims and at the end of processing I only had 2156 claims, I would be instantly alerted to an error.

Field 3. Patient Control Number - This alpha/numeric field can be validated via a table lookup to ensure data accuracy.

Field 4. Type of Bill - The UB92 form contains a unique three character numeric field. This field is two fields in one. Character restrictions can be placed on the first, second, or third character of this field. Example, if character 1 and 2 are “17”, character 3 cannot be “8” or “9”

Field 5. Fed. Tax No - This field requires the submitters 9 digit numeric tax ID. If the value does not fit into the format of 999999999 the data will not be allowed to pass. This field can be formatted with or without dashes.

Field 6. Statement Coverage Period from and to - These dates are checked for validity. You can not have a “period through” date if you have no “period from.” In addition, a “period through” date cannot come before a “service from” date.

Field 12. Patient Name - Only one type of data can be placed here: last name, first name, and middle initial. Intelligent name extraction can be used to parse the data out. Names never have numeric characters, therefore the data can be limited to alpha entries. The OCR engine will never determine the letter “o” is a zero as a result of this rule.

Field 13. Patient Address - This is a great field for using tools like table lookups, and/or intelligent address extraction. By keying the patient phone number and using a customer supplied table, the patient address can be auto populated. Intelligent address extraction is used to validate and parse the data. Limitations can be placed on character types and data length. Furthermore, addresses can be validated by a US Postal Service address validation tool.

Field 14. Patient Birth date - This field will only contain numbers and these numbers can be translated to any type of date format the client requests. If the date of birth is in the format mm/dd/yy it can easily be released in the format yyyymmdd. Checks can be made to ensure dates are valid and limitations can be placed on certain date ranges.

Field 15. Patient Sex - Three types of responses are valid here: male, female, or unknown. The field length is one alpha character. There are only 3 acceptable responses: “M”, “F”, or “U.” Any other response would trigger an error.

Field 17. Admission Date - This field will obviously only contain numbers, and these numbers can be translated to any type of date format the client requests. This date will be checked to ensure the Admin date occurs between the statement coverage period. If it does not, the operator will be alerted.

Field 18. Admission HR - Two character numeric field. This value must be between 01 and 24. Any other type of value will raise an error flag.

Field 19. Admission Type - One character numeric field. This value must be between 1 and 9.

Field 20. Admission SRC - One character alpha/numeric field. This value can be any numeric or alpha character but can be limited. Ex, this field may never be “z”, “x”, “g”, “6”, or “l.”

Field 42. Revenue Code - This field contains a 4 digit numeric code. A list of valid Rev. CD’s can be supplied to ensure better accuracy.

Field 44. HCPCS/Rates - HCPCS codes on UB92 forms can be table verified and their length can be checked to ensure data accuracy. Based upon the revenue code, a table of valid HCPCS codes can be used. For example, a revenue code of “250” could never be used in conjunction with the HCPCS code “99284.”

Field 45. Service Dates - These dates are checked for validity. You can not have a “service date” that falls outside the range of fields 6a and 6b.”

Field 44. Service Units - Typically on a UB92 form, this field must be numeric.

Field 47. Total Charges - This field is validated by using simple math calculations. The Total Charge field must add up to the values on all 23 service lines. This is a great check to spot incorrectly added forms and/or typos.

Field 60. Cert - SSN - HIC - ID No - Many different types of data could potentially populate this field (Social Security Number, Member ID, Medicaid, Medicare, etc…). A business rule on this field can be used to make sure that the field contains valid data. For example, a table lookup can be performed to make sure the ID is a valid member of a health plan. It can even be determined if data is valid, by the format it is in. For example, a SSN must be 9 numeric characters vs. a Medicaid number which must be in an alphanumeric format such as XX99999X.

Field 67 - 75. Prin. Diag. CDs - Table lookups can be used to determine valid diagnosis codes. Default values can also be used when key data is missing. For example, if field 67 contains no data than populate field 67 with data from field 75.

Field 80 - 81. Procedure Codes - Table lookups can be used to determine valid diagnosis codes. Default values can also be used when key data is missing.

Field 82. Attending Phys. ID. - Table lookups can be used to determine valid physicians within a network.

National Provider Identifier (NPI)

Please be aware that a change to the UB92 Form is coming. That change is the addition of an NPI field. The new NPI will now take the place of previously used PIN, UPIN, OSCAR, and National Supplier Clearinghouse (NSC) numbers.

Other Fields - Of course any fields on the UB92 forms can be added or subtracted from the above list. Any rules can be applied, and any workflow can be added. No two providers have the same business rules or workflow. Minimal setup costs are involved for this type of custom solution.