Paper HCFA Form to HCFA 837 Process
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 our Electronic Health
Claim Processing techniques. If you were wondering exactly what a paper
to EDI solution 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 utilizing our electronic claim processing services.
HCFA Electronic Claim 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
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
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
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
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
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,
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
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
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.