Editing text in foreign fonts
The standard Blueprint OMS online forms use the Univers font family, which is likely not installed on your computer. If the fonts used on those forms are not installed on your computer, you will not be able to edit the text while keeping it the same font; you will have to change the font of that entire section of text.
Overview
Creating a PDF online form template is just a matter of following the instructions from Creating PDF templates, and then, optionally, adding text to the field names to make certain fields required or subject to validation conditions. Any template designed according to the normal instructions for creating PDF templates is already usable as an online form, but none of the fields will be required or subject to validation conditions; however, because a form like this is likely to be filled out improperly and thus to require more processing effort, it's recommended to make fields required and to enforce validation conditions.
Follow this general format for form field names: (merge field):(required or not required):(validation type). Here are some examples.
| Merge field | Required | Validation | Example of a text field name | Notes |
|---|---|---|---|---|
 | | | patientBirthdate:req:date | |
| | patientGivenName:req | Everything after "req" can be omitted. | |
| | patientAltContactPostalCode::zip | The "nonreq" designation can be omitted, as that is the default. The colons must be kept. | |
| insuredEmployerSchoolName | Everything after the merge field can be omitted, as, by default, the field is not required and there is no field validation. | ||
| | text1:req:date | Since no merge field is being used, any text can be put before the first colon; it is best to set this so as to ensure that all the form fields have unique names. | |
| text2:req | Since no merge field is being used, any text can be put before the colon; it is best to set this so as to ensure that all the form fields have unique names. Also, everything after "req" can be omitted, as, by default, there is no field validation. | ||
| text3::date | Since no merge field is being used, any text can be put before the first colon; it is best to set this so as to ensure that all the form fields have unique names. Also, the "nonreq" designation can be omitted, as that is the default. The colons must be kept. | ||
| text4 | Since no merge field is being used, any text can be used for the field name. Also, as, by default, the field is not required and there is no field validation, there is no need for the colons or the "nonreq" or validation designation. |
Part 1: merge field name
If you wish to use a form field as a merge field, the first part of the form field's name should be the merge field name, i.e., the name of the merged data that should be pulled into (and later, poss updated by) the field. If merge data exists for the chosen field, it will populate in the form field; if the patient edits that form field, then a Blueprint OMS user's processing the form will make the patient file reflect the new data entered in the form field. You can find the full list of available merge fields at the template tool on the Blueprint Solutions website.
If a form field is not meant to be used as a merge field for merging Blueprint OMS data, enter any text for this part of the field name, and make sure that the fields on the form have unique names.
Updatable fields
The following merge fields can be used to create or update patient files. The other merge fields will display existing data, but cannot be overwritten and used to create or update patient files.
Editability of text fields
For text fields acting as clinic-related merge fields, for example, clinicAddressBlock, it is best to set them as read-only fields, so that patients completing the form cannot click into the field and edit the text. To make a text field read-only, check Read Only in the General tab of its Text Field Properties dialog.
Creating a new patient, alternate contact, or patient insurer, from an online form
If a form is intended to create a new patient, a new alternate contact for a patient, or a new insurer for a patient, then the form should ask for all the same information that is required when a user is creating the same thing in Blueprint OMS. When the form is uploaded to Blueprint OMS, be sure to give it the Processing required property.
Using merge fields with checkboxes
Some merge fields can have only "Yes" or "No" as values when instantiated as text fields. These fields can also work as checkboxes; to do this, just use the same field-naming rules on a checkbox field instead of a text field.
Using merge fields with radio buttons
Some merge fields, such as patientGenderAbbreviation, work best as radio groups. To set this up, set the group name to the merge field name, and set the radio button choice names to the different possible values of the merge field. The form will select the radio option associated with the group's value for the patient, if one exists, and the person filling out the form can interact with the radio group as needed.
Using merge fields with drop-down menus
Some merge fields, such as patientTitle, work best as drop-down menus; this way, the patient will be able to choose from a specified list of options. To set this up, create a drop-down menu form field on the form and name it according to the rules given above for text fields. In the drop-down menu's item list, add all the allowed values for the merge field.
The blank title option
Since an empty text string can't be added to a drop-down menu's item list as an option, you can enter a space for the blank title. Then, the Blueprint OMS user that supervises the processing of the form will have to change this value to the blank title option, in the Create patient or Update patient wizard, because a space is not one of the allowed title options in Blueprint OMS.
Part 2: req or nonreq
After the first part of the field name, enter a colon and then "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.
Whether or not the form has Processing required set, fields can be required. The Processing required property is set, then the field data can be used to create or update a patient file in Blueprint OMS. Even if a form is not intended to create or update a patient file, certain fields, such as a signature or a radio group, might be required because of the nature and purpose of the form.
For more information, see: Special properties of online forms.
Creating a new patient file
To create a new patient file from an online form, the same fields will be required as when you create a patient file using the Add patient button in the patient browser. That means, if you are working on a form that is meant to create new patient files, it should require all the same fields that are required in your system for the creation of a new patient.
In particular, your form should have a required field to capture the patient's referral source. Referral source is not an updatable field because there is only supposed to be a finite list of referral sources, with specific names, and the scheme of referral sources is more for internal use. This means that, when the form is received back into Blueprint OMS after a prospective patient fills it out, the user who clicks to process the form will have to view the form and select the referral source out of the clinic's existing scheme that best matches what the patient had put down.
For more information, see: Handling incoming forms: Create patient wizard.
Creating alternate contacts and adding patient insurers
While certain fields are required for creating new alternate contacts and for adding insurers to patient files, if those fields are set to be required on a form, then the recipient will not be able to submit the form without completing them. If a form is meant to allow patients to proceed even if they do not have alternate contacts or insurers, then the normally required fields for adding alternate contacts and insurers, should not be required on the form.
Part 3: validation
The third part of the form field's name is 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.
In online forms, the format set in the Format tab of the Text Field Properties dialog will not be taken into account.
- 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.
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.
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.
Validation for forms that require processing
To minimize the amount of manual correction that will have to be done in the Create patient wizard or Update patient wizard by the user who clicks to process an incoming online form, use the same validation types that are normally required when you manually enter patients, alternate contacts, and patient insurers into Blueprint OMS.
Hyphens and apostrophes in names
A letters-only text field for a name will not allow patients with hyphens or apostrophes in their names to enter their names.
Canadian health card numbers
Canadian clinics that operate in different provinces with different health card number formats are best off either not having validation on the intake form's health card number field, or having province-specific online forms that have different validation types on the health card number field.