The following Form Standards are recommended to ensure successful integration of custom forms into the Client Tabs. These standards should be implemented when creating custom forms or reviewing existing forms for use in the Client Tabs feature.

General

1. The EchoVantage Database Standards should be followed when creating the custom form's table.
2. Review the Form DesignEHR webhelp for aditional information and recommendations on creating forms and tables.
3. For a form to appear in the + ADD FORM drop-down list in Client Tabs, it must be tagged with the location of CLIENT TAB in the Form DesignEHR Form Properties.
4. Custom forms should go through a Quality Assurance review.
   • Fill in data on every field and verify that each field is saved to the database table.
   • For memo fields, fill in at least 200 characters worth of information.
   • Access the form from multiple clients.
   • If multiple versions of the same form are used, review each version to ensure expected behavior.
5. A Client Tab custom form should never display information from another client.

Custom Forms on Client Tabs

1. Custom forms for use in Client Tabs must have a Client column in the form table.
   • Client is the Primary Key in the Clients table.
   • The Client column should have a Foreign Key restraint.
   • A custom Client Profile form is an exception to this rule.
     • A custom Profile form must be configured to point directly at the dbo.Clients table.
     • A child table used to collect additional information must be linked via the id field, NOT Client.
     • The id column should have the Foreign Key restraint.
2. NEW or DELETE should not be allowed on the top-level form.
   • These functions will be disabled by the application if they do exist on the top-level.
   •  NEW and DELETE is allowed in a Data Grid.
3. The Client Tabs custom forms should not be signable.
   • Signatures are disabled on the top level form.
   • If a pop-up form is used, it can be signable.

Custom Versions of Core Forms

A core form itself should not be altered. If customizations to a core form are desired, the following is recommended:

1. A copy of the core form should be made.
   • Changes and additions can be made to the copy.
   • Multiple copies can be made if different versions of a core form are needed. For example,
     • A read-only version of a core form would allow the agency to control which fields are visible.
     • An editable version of a core form may have additional fields.
   • This keeps the core form in tact and avoids creating a new form from scratch.
   • Writing a new version of a core form from scratch may render some features inoperable due to some custom functionality contained in the core forms.
2. Relabelling a field in the custom (copied) version of a core form is okay, but a field should not be repurposed for other things.
   • Relabelling Client to Consumer or Patient is fine because it is another word for the same thing.
   • Relabelling Date-of-Birth to Date-of-Death is NOT fine because it has a different meaning.
     • This could interfere with in-application calculations or processes.
     • Repurposing a field could also interfere with state and other reporting
3. Changing the label of a field will not propagate through the entire application. It only affects the label on the custom form. 
4. Do not alter the core tables in any way.
   • A child table can be used to store data for any fields added to core form copy.
   • The child table should have a one-to-one mapping to the base table.
     • Recommended name for the table is CoreTableName_Custom (e.g. Enrollments_Custom).
     • The child table needs a Foreign Key column that is Unique and links back to the core table (e.g. Enrollment).
     • On the form itself, the fields in this table will need to be added in a data container.
   • It is okay to add many-to-one relationships with the core table as long as the core table itself is not altered.
5. Do not repurpose the Profile, Enrollments, or Episodes tabs for forms that are unrelated to those things. A custom tab should be created instead.
6. Proceed with caution if altering validations (drop-down listings) is considered.
   • Some validations are tied into Meaningful Use certification requirements or state reporting. Some examples are:
     • Birth Date
     • Employment Status
     • Episode Status
     • Ethnicity
     • Ethnicity (State)
     • Income Source
     • Legal Gender
     • Legal Status
     • Language
     • Living Arrangement
     • Marital Status
     • Race
     • Veteran Status
   • Validations populated from a Defined List should continue to be managed from Configuration>Setup>Defined Lists.