Core Benefits

Business Logic

In addition to forms having general commonalities, each form has its own individual needs.  Some needs cannot be fully addressed by the broader swath technologies. Targeted needs arise at the field level, and need to be addressed at the 'micro' field level.

Data Accuracy and Validation

Not just completing the form, but completing the form accurately is implicit in the reason for the form existing in the first place.  Accurate data is critical to the person receiving the form to taking action appropriately.

MultiForm's Internal Languages

To address business logic forms needs at the 'micro' level, MultiForm utilizes its own internal Form Languages.  These internal programming languages allow MultiForm to drill down to very specific needs on a form by form and field by field and need by need basis.  It provides for any conditional processing specific to any form or field or event. These abilities impact the useability, friendliness, accuracy, and speed of completing forms.  Following are examples of the processing power addressed by MultiForm's Internal Languages (which we call LASDOX, FASDOX, and XASDOX)...

The following list is not a complete list of all the abilities, but the list should give enough example to evidence that virtually any complexity business logic necessary to the accurate and timely completion of forms can be easily handled.

• On Field Entry Conditions

For example, upon moving into a date field, if that date is blank, then insert the current date.  Otherwise, if the field already has a date in it, do not disturb the existing date.

• On Field Exit Conditions

An excellent example of an exit condition would be upon moving out of a date field, where check would be made that the date entered is in fact a valid date, and not a date like 02/30/2006.

• Individual Field Help

A particular field might need special instructions to assist the accurate completion of its data.  With Individual Field Help, instructions specific to that field are displayed automatically.  No action is needed other than just moving to that field.

• Date Handling and Validation

Any date handling and validation is available. Any date math is available. For example, a form has 2 date fields – one is the current date, and one is the date of the closing. On this particular form, the current date must be within 30 days of the closing date. Upon exiting the field the date entered is checked a valid date AND that the data is within 30 days of the "Closing Date" field, and if not, a dialog box is thrown up complaining about the incorrect entry.

Date shorthand can be implemented. Say for instance a date of "1011" is typed. This short version date would be expanded to "10/11/2006". Or "021105" would be expanded to "02/11/2005". Or any variation of input or output formats. "1011" could be expanded to "October 11, 2006"

• Edit Mask Validation

Edit Masks are templates that assist in achieving consistently formatted data.  For example, telephone numbers, dates, case numbers, etc. typically have one or more formats that are imposed upon the data.

In the Conditional Field section below, an "EFT" answer will make a Bank Routing Number Field appear (among other fields as well).  All US Bank routing Numbers are 9 digits.  Anything else would be an incorrect answer.  An edit mask would look for 9 numerical digits, and would complain until a conforming number was entered.  Once a number conformed to the nine digits, further testing could be used to determine if it was a valid Bank Routing Number in the universe of Bank Routing Numbers.

• Nested If/ElseIf/Else Statements

The Internal Languages are capable of handling nested levels are if-then-else logic, which increases the complexity and malleability of the logic that can be handled.

• Pointers

The MultiForm Internal Form Languages are capable of handling pointers.  This ability just means that the code can handle levels of indirection as needed to accomplish the task at hand.

• Lookups

Fields can lookup data from other data sources.  One such example is say selecting from a lists of HIPAA or HCPCS or ICD9 codes.

• Conditional Fields

Conditional fields are fields that conditionally appear on the form.  Depending upon how a field is answered, there is or is not a need for other related fields on the form.  That is, the form can mutate as needed.

For example, one field on a form, "Type of Payment" takes 2 answers, Either "EFT" or "CHECK".  If the answer is "EFT" then additional fields are needed for this answer — such as Account Name, Account Number, Routing Number, etc.  However, if the answer is "CHECK" then these fields are NOT needed and should not even appear on the form (either input screens or printouts) to confuse the issue.

• Field Population

Conditional Field Population speeds up completion of the form and improves its accuracy.  For example, on an Prudential expense reimbursement form, selecting the type of expense from the pop-up Smart Answer List will not only fill out that field, but also will insert the accounting account number and account description into those corresponding fields.  Completing 1 field in this example actually completes 3 fields.

• United States Postal Service Electronic Postmark (USPS EPM)

Business Logic