Creating online form templates: Word

Overview

This page lists the rules for adding online forms capability to an existing .doc form template.

There will be four types of changes to make:

• Adding properties to an editable text field, to associate the input with an online-form-updatable field in Blueprint OMS
• Enforcing input format validation for editable text fields
• Creating checkboxes and dropdown menus that correspond to online-form-updatable fields in Blueprint OMS
• Setting text fields, checkboxes, radio groups, dropdown menus, and eSignature fields as required fields on the form, as needed

General format for a text-type editable field: {{merge field name}}[field type:merge field name:required or not required:validation type]

To define an editable field, type the field specification into a table cell. The table cell will become the container of the field.

Here are some examples of ways to define text fields on an online form. All the examples below have a field type because a field type is required for defining a field on an online form.

Merge field	Required	Validation	Example for a single-line text field	Notes
			{{patientBirthdate}}[text:patientBirthdate:req:date]	The part in braces, {{patientBirthdate}}, populates the existing patientBirthdate value for the patient. The part in brackets turns the table cell into an editable text field that: identifies the input as the patient's date of birth, requires an input, and forces the input to be a date.
			{{patientGivenName}}[text:patientGivenName:req]	Within the brackets, everything after "req" is omitted, as, by default, there is no validation for the field.
			{{patientAltContactPostalCode}}[text:patientAltContactPostalCode::zip]	The "nonreq" designation can be omitted, as, by default, fields are not required.
			{{insuredEmployerSchoolName}}[text:insuredEmployerSchoolName]	Within the brackets, everything after the merge field name is omitted, as, by default, fields are not required and have no validation.
			[text::req:date]	Within the brackets, the slot for the merge field name must be left empty.
			[text::req]	Within the brackets, the slot for the merge field name must be left empty, and everything after "req" is omitted, as, by default, there is no validation for the field.
			[text:::date]	The slot for the merge field name must be left empty. The "nonreq" designation can be omitted, as, by default, fields are not required; this results in another empty slot.
			[text]	Within the brackets, everything after the field type is omitted, as, by default, no merge field is used, the field is not required, and there is no validation for the field.

Part 1: field type

Single-line text field: text

Multi-line text field with text snippet capability: textarea

Drop-down menu: select|value1|value2...

At least one value is required.

Checkbox: check|value|current value

The "value" and "current value" slots are optional. The checkbox is checked when the "value" and "current value" are the same. You can use a merge field here. No more than one checkbox can go in a table cell.

Radio button: radio|group|value|current value

The "current value" slot is optional. On the online form, the radio button will be selected when the "value" and "current value" slots populate with the same information. You can use a merge field as the current value. No more than one radio option can go in a table cell.

Electronic signature: sig

Part 2: merge field name

For the second part of the field name, after the first colon, enter the name of the merge field that the input data should be mapped to.You can find the full list of available merge fields at the template tool on the Blueprint Solutions website.

Part 3: req or nonreq

For the third part of the field name, after the second colon, "req" to make the field a required field, or "nonreq" (or alternatively, nothing, since "nonreq" is the default) to not make the field a required field.

Non-text fields such as checkboxes, radio groups, and drop-down menus can also be made required using the "req" designation.

Part 4: validation

For the fourth part of the field name, after the third colon, enter the type of validation that will be enforced by the field. This third part only applies to text fields and can be omitted for other types of form fields and for text fields that don't require any specific format for the input.

Here are the options you can enter:

• date, optionally date(format)

  Enforcing a date format

  If no format is used, the system's default date format will be used.

  To enforce a format, use the following designators, as well as any other characters:

  • d for numeric day of the month, with no leading zero
  • dd for numeric day of the month, with a leading zero
  • m for numeric month, with no leading zero
  • mm for numeric month, with a leading zero
  • yy for the last two digits of the year
  • yyyy for all four digits of the year

  Example

  The m/d/yy format can populate a date like 2/3/99, for February 3rd, 1999.

• email
• tel
• zip
• postal

• letters_only, optionally letters_only(min length|max length)
  

  Example: middle initial

  Setting the min length and the max length to 1 allows only one letter to be entered as the field's input.

  This could be used for a middle initial field: {{patientInitial}}[text:patientInitial::letters_only(1|1)].

• numbers_only, optionally numbers_only(min length|max length)

  Example: certain health card numbers

  In British Columbia, the Personal Health Number is ten digits long.

  This could be used for a health card number field in British Columbia: {{patientHealthCard}}[text:patientHealthCard:req:numbers_only(10|10)].

  
  

• To create custom validation conditions, use the following guide by W3Schools: https://www.w3schools.com/tags/att_input_pattern.asp

  Example, certain health card numbers

  In Ontario, the health card number is ten digits followed by two letters.

  This could be used for a health card number field in Ontario: {{patientHealthCard}}[text:patientHealthCard:req:[0-9]{10}[A-Za-z]{2}].