About HCFA Forms Processing

The HCFA form is one of the most popular forms in the health care industry today. If filled out correctly, all the data on an average HCFA form can be extracted in just a few seconds. Unfortunately, many doctors do not feel the need to fill these forms out correctly. Consequently, we all pay, but we can pay less.

We can pay less by using digital HCFA processing techniques. If you were wondering exactly what a digital conversion entails, and what data is extracted from a HCFA claim, please review the rest of this page.

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

HCFA Form processing sample

Julian Date or Control Number - Every HCFA form that is processed must be stamped with an easy to read number, which will differentiate that claim from every claim submitted in the future. These numbers also act as a great way to track claims once they have been processed. The 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 I claims, I would be instantly alerted to an error.

Field 1. Insured ID - Many different types of data could potentially populate this field (Social Security Number, Member ID, Medicaid, Medicare, etc…). Business rules should be used on this field 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 2. 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 in them, 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 3. Patient Date of Birth - This field will obviously only contain numbers and these numbers can be translated to any type of date format the client requests. If 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. I’m fairly confident that no one was born before today’s date, but I have seen claims with DOB’s to the contrary.

Patient Sex - This is part of field 3 and can only have 2 types of responses: male or female. If both, or no boxes are checked an error is displayed to our operators. Usually a good look at the name will simply reveal that information.

Field 5. Patient Address - This is a great field using tools like table lookups, and/or intelligent address extraction. By keying the patient phone number and using a customer supplied table, the patient's 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 are validated by a US postal service address validation tool.

Fields 12 and 13. Signature Fields - These permission fields are particularly important when it comes to paying claims. These fields can either have a signature allowing information to be released, or authorization to pay a claim on behalf of the patient. Mark sense boxes are used to extract this information, either there's data there or not. Some providers request that field 13 must have a signature present in order to process the claim.

Field 21. Diagnosis codes - Many doctors simply do not know how this field is supposed to be filled out, therefore the HCFA Form must be corrected. Rules can be put in place to validate the data in the field as well as the correct positions of each diagnosis code. Sometimes submitters find it necessary to place the diagnosis codes on the service lines (field 24E), or put the codes on line 1 and 3 instead of 1 and 2. We code for those instances to ensure the diagnosis codes are always in the correct spot.

Field 24a & 24b. Dates of Service - These dates are checked much the way dates of birth are checked. You can not have a “service to” date if you have no “service from date.” In addition, a “service to” date can't come before a “service from” date.

Field 24b. Place of Service (POS) - This is a great field for table validation and/or character length restrictions. The value is compared to customer supplied data to ensure the POS is valid. Translation methods to correct old POS codes can be used as well.

Field 24d. CPT codes and Modifiers - CPT/HCPCS codes can be table verified and their length can be checked to ensure data accuracy. The modifiers can also be checked for amount of characters they contain.

Field 24e. Diagnosis Codes - This field is supposed to be filled out with the one of the following choices: 1 or 2 or 3 or 4 or 12 or 123 or 1234 or 13 or 134 or 14 or 124 or 23 or 234 or 34. If field 21.1 is the only Diagnosis code filled out, then 24e could by rule only have a value of 1. Every possible number combination can be accounted for, and there are rules devised to guard against incorrect data. A diagnosis code could never be keyed out on the service lines because that would violate another rule.

Field 24f. Charges - It seems straight forward and it is. Simple character filtering is used to ensure no letters ever make their way into this field. Money only, thank you.

Field 24g. Days or Units - Many doctors simply do not fill this field out. A blank value in the ANSI EDI 837 may cause a claims adjudication system to reject the claim outright. If the service dates are filled out and the days or units are blank, a rule can be implemented to place a default value for the days or units field.

Field 25. Federal Tax ID - This field requires the submitters' 9 digit numeric tax ID. If a value does not fit into the format of 999999999 than the data will not be allowed to pass.

Field 26. Patients Account No - This field can be validated via a table lookup to ensure data accuracy.

Fields 28, 29 and 30. - These fields are validated by using simple math calculations. The Total Charge field must added to the values on all six service lines. Field 30 must equal the Total Charges field minus Amount Paid Field. These are great checks to spot incorrectly added forms and or typos.

Field 31. Signature of Physician - This field is always manually keyed because most doctors actually sign the form, and unconstrained handwriting is never a good OCR candidate. Many times this field can only be filled out with a physician's first and last name.

Field 33. Physician's Info - Intelligent data extract is used here much like in field 5. Many providers request HCFA Forms be rejected and returned when this field is not filled out. Another part of this field is the pin number which can be filtered in many different ways.

National Provider Identifier (NPI)

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

Other Fields - Of course, any fields on the HCFA 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.