Skip to main content

Tag: form functions

How To: Carry Referral Source and Referral Reason Forward on Intake from Accepted Referral

Dean Leave a comment

This post comes from a reader request. The scenario she was facing is that when a referral is created in myEvolv, you must enter a referral source and a referral reason on the form. When you go to perform an intake from the referrals, this information is not pulled into the client record. She wanted to have the Referral Source and Referral Reason fields on the client initial enrollment AND also have those fields pre-populate with the options that were selected on the referral.

Intake Form Setup

The Initial Enrollment from Accepted Referral form is in the Agency Intake form family. Agency intake events are not user modifiable so we have to modify the system form to add the fields for Referral Source and Referral Reason.

Referral forms use the refrerrals_to_agency table and the intake forms use the service_track table, so we will need to add new database fields to the intake form to hold our Referral Source and Referral Reason values. We will set them up just as they are on the referral form, using the same picklist and and dependencies.

Referral Source

We add a new database field called udf_referral_source and give it the following attributes:
Data Type: Foreign Key ID
Foreign Key Column: group_profile: group_profile_id
Look-up Table Used: Referral Source – Referral In
Formset to call: Outside Organizations Stand Alone
Depends On: Agency

Referral Reason

We add a new database field called udf_referral_reason and give it the following attributes:
Data Type: Foreign Key ID
Foreign Key Column: referral_reason: referral_reason_id
Look-up Table Used: Referral Reason Table

Default Values

At this point, the intake form has a place to store the referral source and referral reason but the user would have to manually re-select those values, which is a pain and also error-prone. We know the information is in the referrals_to_agency table, so we can use the getDataValue() form function to obtain the data but how do we know which row to select.

When you perform a client intake from accepted referral, the intake event “belongs to” the referral made event. The referral made events are the subform entries for Program Recommendations on the Referral form. In turn, those referrals made events “belong to” the referral form that houses the referral source and referral reason data we need. Once you have selected the accepted referral from which you are completing the intake, myEvolv sends a belongs2Event parameter to the intake form so that when the intake is saved, the intake is linked to the parent referral made. That value is equal to the event_log_id of the referral made event, which means we can plug it into the getDataValue() form function to get the value that referral made event’s parent event_log_id and then use that value to return the referral source and referral reason values.

referral-form-explanation

Referral Source

We use this code in the Default Value attribute:
var parent = getDataValue('event_log', 'event_log_id', belongs2Event, 'belongs_to_event');
getDataValue('referrals_to_agency', 'event_log_id', parent, 'referral_source');

Referral Reason

We use this code in the Default Value attribute:
var parent = getDataValue('event_log', 'event_log_id', belongs2Event, 'belongs_to_event');
getDataValue('referrals_to_agency', 'event_log_id', parent, 'reason_id');

Explanation of Code

First we use the belongs2Event value that is passed to the intake form from the referral made event so that myEvolv can properly link the two events in the tables. We use that value to get the event_log_id of the referral made event’s parent event which is the referral event using the form function getDataValue()

We then use referral event’s event_log_id to get the value of the referral source and referral reason fields on that referral event again using getDataValue()

Conclusion

With this setup in place, when you perform an intake from accepted referral, the referral reason and referral source from the related referral should be on our intake form. Note that this setup enters duplicate data to what is on the referrals_to_agency table into your service_track_x table. If we wish to avoid saving duplicate data to the database, we can setup the new fields on the Intake form as variables instead. This will allow us to display the referral source and referral reason on the intake form when it is opened in myEvolv but no data from the variables will be saved to tables when the intake is saved.

How To: Make a Field Required Based on Client Age

Dean 2 Comments

I haven’t yet figured out a great way to only toggle the required attribute for a form field so the typical workaround for a conditionally required field to be used on a form is to toggle the form field to be required all of the time but enable or disable the field based on the condition you want. myEvolv ignores disabled fields when it goes to save, even if they are required so you can get most of the functionality you would want in this way. The one scenario you don’t get is if you want the field to remain enable but no longer be required. That’s where being able to have a ‘required rule’ attribute in the form designer would be nice. I am not convinced that there isn’t a way to do this through some clever JavaScript but I haven’t had the opportunity to try anything out yet.

Form Setup

The nice thing about this approach to the problem is that you don’t need to add any additional information to the form itself. A lot of the disable rules that you might learn will involve checking the value of other fields on the form. In this case, we are going to use a form function to check a value in the database behind the scenes.

All you need to do then is setup the field that you want to make required. Be sure to check “Required” for the form field.

required-form-attribute

Disable Rule

The key to using the Disable Rule attribute in the form designer is that you have to put in a conditional statement that will resolve to true when you want the field to be disabled. It’s somewhat counterintuitive but basically true = disabled and false = enabled.

For this example, we want to figure out if the client is under the age of 18. If the client is under the age of 18, we want to enable the field and require that the clinician enter some data. If the client is over 18, we want to disable the field. So our statement should look something like this:

[[client_age]] > 18

If [[client_age]] is under 18, the statement resolves to false, so the field will be enable. If the client is over 18, the statement resolves to true and the field will be disabled. Now we just need to get the client’s age.

The getDataValue Form Function

One of the JavaScript form functions that myEvolv has included in it is the getDataValue() function. It is used to get a value from a column in the database based on the value of another column in the same table. It takes five arguments, one is an optional conditional statement that we will not get into here. For our purposes, we need to supply it with 4 things:

  1. the table we want to get data from
  2. the column we will match on
  3. the column value we will match on
  4. the column value we want returned

myEvolv has a view called the client_personal_view which contains a calculated column for the client’s age, so the work of calculating an age has been done for us already.

So to get the age of the client we are entering a service for, we call the function like this:

getDataValue('client_personal_view', 'people_id', keyValue, 'age')

Here we are saying, get the value in the age column from the client_personal_view table in the row where the value of people_id column is equal to client_id of our current client. keyValue is a variable that myEvolv creates to hold the client_id when a service event is launched so we can use that in our JavaScript here instead of getting the value from the people_id form field, though that is also a valid option.

The full code for our disable rule is now:

getDataValue('client_personal_view', 'people_id', keyValue, 'age') > 18

Remember, the “>” and “<" signs are special characters so we have to use the ascii codes or else you will throw an error when the form loads in myEvolv.

How To: Prevent Backdated Entries

Dean Leave a comment

This may not be the only or even best way of preventing backdated entries in myEvolv but this method worked for me in a recent configuration.

Scenario

We wanted our prescribers to be able to provide a Script for Therapy Services to children in our preschool services program from myEvolv. Scripts for Service must have a start date on them and that start date needs to be no earlier than the date indicated on the child’s IEP but cannot but previous to the date that the script is being signed.

Further, an administrative assistant was going to be setting up the scripts in myEvolv and then the prescribers were going to be reviewing and e-signing them. We could imagine a scenario where the administrative assistant put a date, for example (9/1) on the script, believing that the prescriber would e-sign it on or before that date but the prescriber does not get into myEvolv to sign it until after that date has passed and then the script gets e-signed as though it were backdated. We needed a way to prevent the start date from ever being previous to the approved date while also allowing the start date to be in the future.

Form Design

script-for-service-form

The actual_date field was not suitable for use as the script start date since we needed to be able have multiple scripts that start on the same day for an individual. If I set the actual date as ‘Date Only’ Display Type Code, then two scripts in the same day would overlap at 00:00 AM. In this case I ended up creating a new database field for my Start Date and kept actual date on the form, receiving todaysDate() as the default value. This more or less prevents the service overlap problem. My new database field is named udf_rx_4_svc_start and is Date Only.

The end date on the script is using the expiration_date column and is also using the Display Type Code “Date Only”.

Before Save Code

The first task to accomplish is to prevent a user from saving the form with a backdate on it. For this I used the Before Save code property on the form. This code executes every time that the form is saved BUT because of the algorithm myEvolv uses to save form data, the udf_rx_4_svc_start column in the database will only be updated if the form field has been flagged as being modified. This is something that I was not able to figure out how to do in the Before Save code yet and is largely responsible for what feels like a more-complex-than-is-strictly-necessary-solution — more on that later.

First step is to get the value that is on the form field and turn it into a JavaScript date object.
var start = new Date(getFormElement('udf_rx_4_svc_start'));

Second step is to get today’s date and turn it into a JavaScript date object. todaysDate() is a myEvolv form function that you can use to get today’s date in a format suitable for placing in a myEvolv form field.
var today = new Date (todaysDate());

With that accomplished, we can compare the two date objects to see if the date on the form is previous to today’s date and if so, set the form field’s value to today’s date.
if(start <= today){{setFormElement('udf_rx_4_svc_start', todaysDate())}};

Note that the { and } brackets are doubled up in the conditional statement. This will prevent the “Not a Valid XSLT or XPath Function” error previously discussed here.

With this code in place, when a new Script for Service is entered or a draft Script for Service has it’s udf_rx_4_svc_start field modified, myEvolv will check to make sure that the start date is not not in the past and if it is, update the start date to today’s date. If the date is today’s date or a future date, it is left as it is.

Full Code Block

var start = new Date(getFormElement('udf_rx_4_svc_start'));
var today = new Date (todaysDate());
if(start <= today){{setFormElement('udf_rx_4_svc_start', todaysDate())}};

On Load Script

Just the Before Save Code alone would not be enough to prevent backdating. We still have the possibility of someone simply opening the draft and e-signing the form as in our scenario where the prescriber gets into myEvolv to e-sign scripts later than intended. Even if the form is edited in some way, if the Start Date is not touched, the Before Save code will execute but the column will not be flagged as modified and myEvolv will ignore it when updating the database. My approach here was to try to update the form as it loads upon viewing or editing so that myEvolv would see the column as modified when saving. I was unable to get the toolbar containing the ‘Save’ button to recongize the change, however, I was able to still get the desired effect another way.

The first thing to keep in mind with the On Load Script is that the form DOM has not loaded yet when this code runs. You can not therefore target the form field with JavaScript, update its value and focus/blur to make myEvolv notice a change to the value as we can with the On Click and On Change Scripts. Instead, you have to manipulate the Record XML Data before it gets loaded into the form.

The first step here is to determine whether the script had been signed. If it has been signed, it will have a non-null date_locked value. We check for this by using the myEvolv form function getDataValue() and then seeing if the form is being opened for viewing or editing.

var locked = getDataValue('event_log', 'event_log_id', keyValue, 'date_locked');
if(locked == '' && formXML.documentElement.getAttribute('formAction') == 'EDIT'){{
...
}}

This code gets the value of date_locked from the event_log table where the event_log_id is equal to keyValue which is a variable equal to the event log id of the current event you are looking at.

Then the code checks to see if there is a locked_date. If the locked date is blank AND the form is opened for editing, then it will execute the rest of the code. So basically, only perform a date manipulation if we are still working with a draft. If you leave this piece out then every time you look at a completed script for service in the future, myEvolv will overwrite the form field value for start date to be today’s date and you will be scratching your head.

Inside the ellipses we start the date manipulation. First we load the node for udf_rx_4_svc_start from the XML Record so that we can manipulate it.
node = formXML.documentElement.selectNodes("form_group/form_item [@column_name = 'udf_rx_4_svc_start']");
node = node[0];
This code returns an Array of all of the nodes in the XML documents with the column_name “udf_rx_svc_start”. There is only one but it is in an array so we load it into our variable directly on the next line.

Then we get the start date value and turn it into a JavaScript date object.
var start = new Date(node.text);

Then we do the same for today’s date.
var today = new Date(todaysDate());

Now we check to see if start date is before today’s date and if so, we will update the text of the node to be today’s date.

if(start < today){{
node.text = todaysDate();
node.setAttribute('modified', 'true');
...
}}

I also set the “modified” attribute to ‘true’ for this node. I don’t know if that makes a difference in this setup but I am including it since that is how my code is and it works.

If you leave the code as it is like this, when the form loads, if the start date is previous to today’s date, the value on the form will have been updated to today’s date AND the form field will be maroon like it is when a form field is changed. However, you will also notice that the “Save” button is nevertheless disabled and a user would be able to e-sign the service without being forced to hit save. And apparently, even though a “saving…” dialog pops up upon e-signing, the form is not saved. I tried a bunch of things to try to get the save button to enable and the e-sign button to disable but it is difficult since the form DOM is not loaded at the time that the On Load script runs. In the end, I decided to just call the save form function directly.

So where the ellipses above are, I put
SaveForm2();

The end result here is that when the form is opened for editing, if the start date is before today’s date, myEvolv will update the start date to be today’s date and then save. The users will see the form start to open and then abruptly close if the conditions are met. When they reopen it, they will find that today’s date has been updated to today’s date and they are free to e-sign.

Full Code Block

var locked = getDataValue('event_log', 'event_log_id', keyValue, 'date_locked');
if(locked == '' && formXML.documentElement.getAttribute('formAction') == 'EDIT'){{
node = formXML.documentElement.selectNodes("form_group/form_item [@column_name = 'udf_rx_4_svc_start']");
node = node[0];
var start = new Date(node.text);
var today = new Date(todaysDate());
if(start < today){{
node.text = todaysDate();
node.setAttribute('modified', 'true');
SaveForm2();
}}
}}

Bonus: After Save Code

Since the form is going to be auto-saving itself, I also added a snippet of code to the After Save Code that keeps the form from closing after save:
window.closeAfterSave = false;

We are using cookies on our website

Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.