Required or Suggested Data Entry Fields

One method that administrators can employ to ensure that the appropriate patient data is collected when patents are registered is to use required or suggested fields to either force users to enter some specific data or to draw attention to data that should be captured during the normal patient registration/maintenance workflow. These fields are configured on the Required and Suggested Fields screen in Data Maintenance > System and Security > Required Fields.

Required Fields: Data that is required must be completed to save the portion of the demographic record in which the data appears. For example,

First and Last Name must always be completed in every patient record. Each organization can then configure additional data from patient and case demographics as additional requirements for saving the patient. For example, to require that an account number is actually created when new patients are registered (saved), the Account field must be configured as required in the Patients table (illustrated in the following screen shot).

In addition to requiring data for saving the patient, other data may be required to complete (save) a portion of the demographic record in which the data is actually entered. For example, patients may not always have an authorization for treatment. However, administrators can configure certain fields in the authorization data entry form as being required to ensure that if one is created, the necessary information is obtained.

Additionally, some appointment data can be required to complete—i.e., schedule—the appointment.

All required data is displayed with the field labels set in red text or with an asterik. This is true of supporting data as well as patient information that you configure as required. Any required field on a data entry form must be completed to save that record.

Suggested Fields: These are data entry points that your organization wants to capture. They are displayed in yellow or in golden rod (depending on the current background) to distinguish them from required fields and to alert users that they should capture this data if at all possible. However, failure or inability to enter data in these fields does not prevent the record from being saved.

Key Considerations Going Forward with Requirements

In general, when thinking about patient data entry requirements, administrators should consider whether something should be

Required to save the patient record itself
Required to save the specific portion of the demographic record in which the data appears

They should also consider what the minimum requirements are to register or save a new patient. Again, the program’s default requirements are the patient’s (a) First and Last Name and (b) where applicable, at least one domain. Any additional data required by the organization’s workflow must be configured by the program administrator.

Requirements for Saving a Patient

The tables containing the fields that are used for requirements appear in a drop-down in the Required Fields panel of the Required and Suggested Fields screen. Each of the following bullet point (a) corresponds to a portion of the patient demographic record and its related data entry fields and (b) is listed in a rough hierarchy with data from the other tables. For example, a patient must exist before you can require an insurance plan or an inpatient record, a case must exist before you can require an authorization, etc.

Patients In addition to the First and Last Name administrators can set additional requirements on the patient’s demographic data: e.g., Address, Phone, SSN, etc.

Accounts/Cases In order to require an account number or case to save a patient, you must require the Account/Case in the Patients table first.

Inpatient In order to require an inpatient record, you must configure Inpatient as required in the Patients table. Note that if you configure Inpatient as required but do not require the Case, the system will automatically do so because inpatient records must have a case assigned to them.

The Inpatient category is the only data element that has a prerequisite like this.

Responsible Party In order to require a responsible party to save a patient, you must set Responsible Party as required in the Patients table.
Authorizations In order to require an authorization to save a patient, you must set Cases as suggested/required in the Patients table and Authorization to required in the Cases table. If for example, you just set Authorization as required and don’t configure Case to be required or suggested, then the Authorization requirements will be ignored when the patient is saved.
Referrals In order to require a referral, you must set Cases to suggested/required in the Patients category and Referrals to required in the Cases category.

Patient Insurance Plans In order to require an insurance plan to save a patient, you must require the Patient Insurance Plan in the Patients table first.

Appointments Any field you require here must be completed on the Edit Appointment screen in order to schedule an appointment. As long as an Appointments field is configured as required, the Edit Appointment screen will continue to appear—even if the “Use Extended Appt Making” option is disabled in System and Security or the Domain definition where applicable.

As an alternative, configure any of the above a suggested, which will cause the forms to appear for optional data entry, but not require the data to save the patient record.

Requirements for Saving a Portion of the Demographic Record

The second level of requirement configuration relates to data that is required or suggested if and when a particular portion of the demographic record is created. The key consideration of this requirement is that unless data is actually entered in the portion of the demographic record to which a requirement relates, users do not have to enter the data to register the patient. For example, you could configure the data so that

When you create an Authorization (whether or not the Authorization is required), you must enter an ID, Visits, and Begin Date.
When you enter a Responsible Party, you must include the patient’s SSN.
When you enter an Insurance Plan, you must enter the Group Number and Policy Number.

If data is never entered in a portion of the demographic record in which a requirement has been configured, then the requirement is never triggered and the patient can be saved normally.

Simple Illustrations of Requirements

Consider the following scenarios that illustrate a very restrictive set of requirements to save a patient and one without restrictions:

To create a patient, all that the program requires is that you enter the patient’s First and Last Name, but you could create the following chain of requirements:

Configure the Case as required to save a patient in the Patients category.

Configure the Authorization as required to save the case in the Cases category.

Configure the Authorization Begin date as required to save the authorization in the Authorizations category.

With the previous requirements, a patient could only be registered when a case is created that contains a valid authorization in which the Authorization Begin date was entered.

Alternatively, if you simply configure the Authorization Begin date as required in the Authorizations category, users will only be required to enter the date when an authorization is actually created, and this requirement would have no general effect on saving a patient record.

Configuring Required and Suggested Fields

Select Data Maintenance > System and Security > Required Fields from the Main menu. The Required and Suggested Fields screen will appear.
Click the drop-down in the Required Fields panel to select the table containing a field on which you wish to place a requirement.

You cannot customize fields that are used for configuring requirements. They are part of the program’s configuration, and cannot be modified by the end user.

Do one of the following:

Click the radio button next to either the Suggested or Required option for the appropriate field line item. Alternatively, select None to reset a field to the default requirement status.

Click the Suggested option to set all of the fields within the selected table to Suggested.

Click the Required option to set all of the fields within the selected table to Required.
Click the None option to reset your requirements on all tables.

Repeat as necessary.
Click Save to commit the changes

You can modify the configuration here any time. Simply follow the steps outlined to change the selections for the appropriate fields as necessary.

Required Fields and Quick-Reg

The configuration on the Required and Suggested fields screen has a purpose beyond setting specific data points as required in the patient registration and appointment workflow. The data you configure here is also used to create a custom registration workflow. The standard registration workflow offered in WellSky Resource Manager generally meets the needs of most users. Occasionally, however, it is more detailed than required for basic registration. With this in mind, a customizable Quick Registration workflow has been provided.

This registration option always appears under Demographics > Quick-Reg a Patient, and it includes the basic patient information illustrated in the following screen shot by default.

Additional data entry panels will automatically be added to the Quick-Reg workflow as administrators adjust the requirements of patient demographic information (outlined in the previous section). For example, patients cannot be scheduled without an account/case, so to ensure that the patient can be scheduled once he or she has been registered, the administrator would configure the Account/Case as suggested/required in the Patients table. Consequently, the Account/Case Information panel will be included Quick-Reg to allow for the case entry.

Note that in domain products, a domain must be assigned regardless of any other requirement setting.

Key Considerations

Some consideration should be given as to what constitutes the minimum information your organization requires to create a patient, and then try to tailor the Quick-Reg to fit those requirements. If you require or suggest everything, you are merely duplicating the default patient registration workflow.
If you configure something as Required or Suggested and it does not show in the Quick-Reg patient entry, then most likely a prerequisite has not been met. An example might be setting the Authorization Number as required in Authorizations without either configuring the Authorization as suggested/required in Accounts/Cases or Accounts/Cases as suggested/required in Patients.
Data that is suggested is displayed in either yellow or golden rod, and the panel in which the data appears is “collapsed” (as long as no other data in the panel is required). Simply click the panel header to expand it.

Required field maintenance is governed by the Global Right "System Preferences."