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
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
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.
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