Skip to main content

How To: Create Multi-Select Form Controls using Driving Form Line

As good as drop-down pick lists are, there are times when you might want the ability to addset of multi-select checkboxes to one of your forms. A set of multiselect checkboxes can make for much faster service entry for your users and is useful in form design to show views of the form what options were available so that they can see what was selected as well as what was not selected.

Creating a multiselect checkbox is not as easy as adding other types of control to your form in the form designer. You will need to create a subform for your main form and perhaps a user-defined look-up table.

The instructions below are going to go through the entire process of setting a fully user-defined multiselect form control but you can use the driving form line in other scenarios if it suits your purpose.

Step 1 – User Defined Lookup Table

For my scenario, I need to create a multi-select checkbox list of types of restraints that my agency uses to support clients. This type of control is a good candidate in this situation because I cannot predict how many of the types of restraints may be used in a single incident. I do not want to have 2,3, 4 or more(?) picklist fields on my form just in case there is a situation where more than one restraint is used.

The first step is to create the list of restraints as a user-defined table.

I simply set mine up like this:

Note that I changed the Order Expression to std_code. This changes the sorting on the lookup table to use the standard code field. I then just simply numbered my options in the order I wanted them to appear on the form. The sorting is alphabetical, not numerical, which means you need leading 0’s or 17 will render before 7.

Step 2 – Subform Design

In order to create something like a multi-select checkbox control, we need to leverage a subform. Subforms have the ability to add new rows as additional selection are needed. For example, here is a subform for one or more attached documents that I have added to forms where we cannot predict how many separate document may end up being attached:

If I add an attached document, a new row is added to the subform for me to add an additional scanned document.

Instead of a document link form element on my subform, I could use a foreign key field that uses my new user-defined table and then I could add as many rows as needed to capture the multiple types of restraints that may have been employed in the incident.

In order to create my sub form, I need to select the right form family. There are a few options for this. You can see them in the form designer when you add a Sub Form to a form (NOT an Event Based Subform) As of this post, there are 26 form families at your disposal, although some may not actually be useful for this:

I usually choose Materials Provided because my agency does not use the materials provided functionality that myEvolv intended so there’s little danger of obtaining weird results somewhere down stream from adding materials provided to random events.

Copy the default form from the top of the list and then on your new form, you can remove all of the fields except the Event Log Id and Agency variable.

Then add a new database field to the form like this:

Note that I am entering user_defined_lut: user_defined_lut_id as the Foreign Key Column — this will allow me to re-use this user-defined column again on other forms. This new field is now linked to my user defined table Restraint Type.

After saving, make sure that only this field is visible on subform. The other two may be hidden or at least hidden on the subform. This is what you should be left with, if using Materials Provided:

Add this subform to your main form. It should look something like this now:

This setup could technically get the job done. Users can select the gray ellipses button and add a row for every type of restraint used. However, there’s a lot of clicking involved and nothing prevents them from selecting the same one twice. Furthermore, we don’t have a sense of what all of the options are to know what was not used, only what was used.

Step 3 – Form Driving Line

There is a setting that has been available for a while but seldom used called Driving Form Line available in the form header properties.

What is does is allows you to select a foreign key field that is on your form and use it to “drive” the creation of subform rows. It will pre-populate your subform with one row per active item in the lookup table associated with the foreign key field you selected and render each with a checkbox next to it. In the database, only those items with a checkbox checked in it will be considered selected.

In my scenario, we will have a row per restraint type in our subform when it renders. Note that you will likely want to increase the size of the subform on your main form to accommodate all of the rows that will be rendered so that users do not need to scroll. My list has 11 items and I have found that you need 25px per item so I will use a height of 275:

Beware: because of this height aspect, you may want to limit your driving form lines to lookup tables with manageable number of options.

P.S. — Other Considerations

The scenario above is the most basic but keep in mind that you can include other columns in the subform. For example, I have another subform that gets the classification of an incident and also asks the use to select if the classification is primary or secondary.

I have a third subform using driving form line that handles information about notifications that have been made.

When you use this method with subforms that contain additional rows, keep in mind that ONLY those rows where the driving form line checkbox is checked will save to the database. This presents a risk for data loss on save that can drive users crazy. They fill in all of the columns but forget to check the box and now they have to re-enter everything.

It is therefore recommended that you use the following JavaScript in the subform design to disable all of the other columns unless the driving line checkbox is checked.

This code should be on the disable rule property for every column that is not the driving form line column. You must provide the correct column name for the code, which is the column name for the driving form line column.

!SubDisableRule('udf_restraint_type', 'checked')

JavaScript Fundamentals: String Concatenation

In my CONNECTIONS2019 presentation, I showed how I use SSRS to create “Pretty Print” versions of myEvolv Treatment Plan components to use as a handout for treatment plan meetings that can be accessed by clicking a URL variable on the treatment plan itself. Several people asked me to share the method and specifically how to do the JavaScript string concatenation, which can be used in many other places.

JavaScript Strings

In JavaScript, strings are any text characters inside of a single or double quote.

var myString = "Hello world.";

You can use concatenation to “glue” strings together. In JavaScript, the concatenation operator is + , just like adding numbers together.

var string1 = "Hello world.";
var string2 = "How are you?";
var newString = string1 + string2;

The value of newString would be Hello world.How are you? Notice that There are no spaces between the sentences because I didn’t include them in the strings.

If you have added a URL variable to a form, you have already used a JavaScript string because you probably entered a default value like this:

'http://www.example.com'

This created a static URL that will always point to example.com every time the form is opened in myEvolv. Using JavaScript variables and string concatenation, you can create dynamic URLs that will be unique to a client, event, staff, or any other things you can come up with and these can be very useful for making myEvolv more user-friendly and effective.

“Pretty Print” Reports

At my agency, we find that the default printouts for things like Treatment Plans are long and difficult to read, especially for people who are not using myEvolv day-to-day. When treatment teams get together to meet about the treatment plan with the client and family members, we were printing copies of the treatment plan to share at the meeting.

Through meeting with the staff in those meetings, we determined that the main focus was to use these printouts to review the component pieces of the treatment plans, so why not come up with a way to just generate a one-page print-friendly list of Goals, Objectives and Methods from the current plan?

I was able to accomplish this using our SSRS Report Server by creating a report that would pull in all of the service_details for a specific plan and displaying them neatly.

Example of “Pretty Print” report

The SSRS Web Portal would allow staff to access the report where I could have added parameters that would allow the staff to lookup a client and select the plan they were looking to print this report for. But it would be easier if they could just click a link and have the report generate for the plan they clicked the link from automatically.

Dynamic URL to SSRS Report

Query Strings

SSRS allows you to pass report parameters through query strings. You may have seen these in web URLs that you have browsed:

http://www.example.com/search?search_term=balloon%20animals&limit=20

The first section of the URL directs you to a search endpoint

http://www.example.com/search

The ? starts the query string and then the parameters and their values are listed. In this case, the search_term is “balloon animals” and we only want it to return (limit) 20 results.

We can do the same thing with SSRS. In the case of this Pretty Print example, I only need one parameter, event_log_id. My query includes a WHERE clause

WHERE event_log.event_log_id = @event_log_id

This creates a parameter called event_log_id that the report is expecting in order to run.

The event_log_id of the Treatment Plan is on the treatment plan so we can use string concatenation to glue the report endpoint and the parameter name to a variable on the plan that holds the value of the event_log_id.

URL Variables

The URL form field type is used to create a clickable button on a form that will launch a new web browser window pointed to the URL value of the field.

You could add the field as a user-defined field and that might make sense if you are doing something like collecting a URL from someone. For example, if you wanted to get the website of an organization. In that case, you want to store the URL in the database.

In this situation, however, we don’t need to store anything in the database. We just want to generate the URL and create the button every time an event is opened, so a variable is perfect in this case. I added mine like this:

The URL field displays the URL in a ext box and then has a clickable globe icon to the right of it. I don’t like to display the url itself because they can sometimes be very long and look terrible so I put 1 in display size. That still shows the first few characters of the URL but that’s the smallest you can get it. As of this writing, the display size does not seem to effect how it looks in NX. I also make my URL variables not modifiable.

Default Value

Now for the JavaScript. We have our SSRS Web portal setup to work on the agency Network only so the url is

http://ssrs:8080/reports

The specific report I have created is located in the Pretty Print Reports directory and is called Plan Components:

http://ssrs:8080/reports/report/Pretty%20Print%20Reports/Plan%20Components

The %20 all stand for spaces

I also know that I have one parameter, event_log_id, so that is going to be a static part of the url:

http://ssrs:8080/reports/report/Pretty%20Print%20Reports/Plan%20Components?event_log_id=

And now all I have to do is concatenate the event_log_id to the end of the url and I will have my link. myEvolv stores the event_log_id of any given event in the variable keyValue, so I can just use that. So in the default value for the URL variable, I will use the following code:

var url = 'http://ssrs:8080/reports/report/Pretty%20Print%20Reports/Plan%20Components?event_log_id=';
url += keyValue;
url;

Explanation: I created a variable called url and gave it the string value of the static portion of my report URL. Then I concatenated the event_log_id of whatever event the form opens with to the end of the string using the myEvolv variable keyValue.

The url variable now holds a value like:

https://ssrs:8080/reports/report/Pretty%20Print%20Reports/Plan%20Components?event_log_id=2542C1F3-2D25-4840-97B3-A17C86652E9F

In the last line, I simply output the value of url, which becomes the default value of the URL variable.

One More Brief Example

To give an idea of a slightly more complicated string concatenation for a URL variable, another place where I use this is on our Monthly Summary events. I have created a dynamic URL variable that will launch an SSRS report where the parameters are the client’s people_id and then a date range. The SSRS Report then pulls in the specified daily notes for that client between those dates so that the summary writers can easily review the months’ activities.

Here’s the code for the default value:

var url = 'http://ssrs:8080/reports/report/Raise%20the%20Age%20Reports/Action%20Step%20Specific%20Notes?people_id=';
url += getElementFromXML(formXML,'people_id');
url += '&start_date=';
url += getElementFromXML(formXML,'udf_summary_start');
url += '&end_date=';
url += getElementFromXML(formXML,'udf_summary_end');
url;

This is pretty similar to the first example but a few difference. One, instead of using a myEvolv variable, I am just concatenating values from the form directly to the string: people_id and two user-defined date fields, udf_summary_start and udf_summary_end.

I am using getElementFromXML() to get the value from the form’s definition rather than the rendered form elements. This works well when you have default values in the form. If you do not, then those values may be null until filled in on the form.

In that case, you might want to go a different route and use similar code to the On Change field of every form element that is used in the URL with t

var url = 'http://ssrs:8080/reports/report/Raise%20the%20Age%20Reports/Action%20Step%20Specific%20Notes?people_id=';
url += getFormElement('people_id');
url += '&start_date=';
url += getFormElement('udf_summary_start');
url += '&end_date=';
url += getFormElement('udf_summary_end');
setFormElement('monthly_summary_report_url', url);

***In this example, my URL’s variable name is monthly_summary_report_url

What this does is any time the client is switched on the form or the start and end dates are changed, a new URL is generated and entered into the URL variable as the value.

In either case, you can see that I am alternating between concatenating static parts of the query string with they dynamic parts to make a more complicated query string.

myEvolv Tips: Reusable User-Defined Picklist Fields

When you are building forms and have to create new database fields, best practice is to give the columns generic names so that you can use them again on other forms in the same form family. For example, if you need to link a tenth diagnosis (yes, the event_log has 9 diagnosis columns!) on a People Activities form, you should name it something like udf_diagnosis10_id rather than for the specific form like udf_extradiagnosisforclinicprogressnote. This will allow you to keep your database neat and help prevent running out of columns in your _x tables.

You may have run into a situation where you setup a user defined foreign key field on one form and had it working beautifully. However, when you went and tried to re-use it on a second form, you found that you could not select any look-up tables to use with it. What happened there?

You missed a crucial step in creating a user-defined database field. Here’s how to avoid making that same mistake going forward.

When you got to create a user defined foreign key field, use the [Data] Foreign Key Column attribute. Like the column name and data type, this attribute is only available when you first create the new column. If you forget this step, you cannot go back, and it is the reason that you cannot link a look-up table on subsequent uses of this column on other forms.

What to choose?

This depends on what picklist(s) you want to use with this column.

For example, if we go with the initial scenario, the picklist I want to use will consist of diagnoses so the foreign key column I want to select is diagnosis_id. This will allow me to reuse the column on additional forms as long as I use a picklist that is diagnosis-based.

User defined fields are commonly paired with a user defined look-up table. In order to re-use these, you should select the user_defined_lut_id foreign key column. Since all of your user defined look up tables use the user_defined_lut table, they all use the same column as their primary key.

If you need help figuring out which column to select, first select the look-up table you intend to use. In the picklist for look up tables, there is a column called “Table From”. Many of these will be views, but you should be able to figure out what the underlying table is in most cases. In our example, I want to use a look-up table from the diagnoses_view and so I know that the diagnosis table and therefore the diagnosis_id column is what I should select.

myEvolv Tips: Subform Field Manipulation

Credit for figuring these out/discovering them goes to Perry. I find myself referring to them in a training binder I got from last year’s NY Training Summit and figured it would be easier to just get them up on the web so I don’t have to go hunting for that binder every time. The following code works for Classic.

Subform Considerations

Subforms have to be handled differently than forms when it comes to JavaScript because while in the form designer, the two things look identical, the way that myEvolv renders a subform in the browser is very different from how it renders a form. But it isn’t radically different and the main changes account for the fact that a subform can have one or more rows and so you need to be more specific about which field you are trying to manipulate so that you don’t change every line simultaneously.

Scenario 1: Get the Value of a Subform Field

This code is for use within the subform, e.g. if you want to default the value of one field based on the value of another on the same subform.

self.getElementFromXML(currentRowXML, 'column_name');

Note the self object is being used here. This is the subform object as distinguished from the parent form object. The parameter currentRowXML then further narrows it down to the current record/row on the subform that you are concerned with.

Scenario 2: Set the Value of a Subform Field

Again, for use within a subform, this code can be used to set the value of a field in the same subform, e.g. when you want the On Change event to auto-populate a field.

this.form.'column_name'.value;

If you are checking a checkbox, use this code:

this.form.'column_name'.checked = true;

Note that in this code, you do keep the single quotes in the code for it to work properly. All you change is the column_name

Scenario 3: Get the Value of a Parent Form Field

With this code, you can get the value of a field in the parent form based on an action in the subform.

window.parent.getFormElement('column_name');

Note the window.parent is the only difference from the code you would use on the parent form. This is what allows your code to ‘jump up out of the subform’.

Scenario 4: Set the Value of a Parent Form Field

Maybe you figured it out by now but you can use the same small change to set values on the parent form from the subform.

window.parent.setFormElement('column_name', value);

Scenario 5: Trigger an Alert from the Subform

Alerts are useful in guiding user activity and you can trigger them from subforms. Similar to the last two, the trick is moving back up the DOM to the parent form to trigger it.

window.parent.window.alert('Alert Message');

Other Possibilities

It is possible to go the other way and get and set values on subform records from the parent form, however, it becomes a much more complex problem that requires very specific solutions for very specific challenges. That is because of the One-to-Many relationship that the subforms have with the parent form. For these types of situations, you will probably be targeting the subform itself and then looping through each record to get or set values.

How To: Enforce ZIP+4 in Client Demographics

Some payors are beginning to require that client addresses utilize the ZIP+4 ZIP code in order to get paid.  The ZIP code field in myEvolv has a datatype of Zip Code which appears to be a string field that allows up to 10 characters.  This means that you can store a 5-digit ZIP code or a ZIP+4 in the field.  Furthermore, the functionality for auto-filling the city and state fields based on the ZIP code will work with either type of ZIP code.

One thing that is lacking is the ability to force users to input a ZIP+4 in the ZIP code field.  The following guide will show how you can add some form validation to the Client Demographics form that will help to prevent users from entering only the 5-digit ZIP code.  While we will be looking at only one set of forms, you should be able to apply the same changes to other forms and address subforms to achieve the desired result elsewhere in the system that addresses are collected or edited.

Setup New Demographics Formset Member

For the purposes of this demo, we are going to modify the Client Demographics form.

This is a system form and we cannot directly make changes to it so instead, we must create a custom demographics form, address subform and formset member so that we can make the changes we want.

Copy the ‘Address by ZIP code‘ Form

This form is in the Address Info for People form family. This is the form that is used for the Personal Address subform on the Client Demographics.

Copy the ‘Client Personal Information‘ Form

This form is in the Personal Information form family and is listed at the top as the default form. This is the main form that loads when you go to the Client Demographics formset.

On your newly-copied, custom version of this form, swap your custom Address by ZIP code subform in for the default Address by ZIP code subform.

Remember that when you copy and begin editing these system forms, a good rule of thumb is to only add to the form or carefully edit what is on the form so that you do not have downstream effects. Avoid deleting elements. If you don’t want them to be visible, simply hide them.

Create New Formset Member

Select the Client Personal Information FormSet in Formset Maintenance. By Default, the Client Demographics formset member is ordered #1. Add a new formset member and copy the settings for it just like the system default Demographics formset member EXCEPT that we will be using our custom Client Personal Information form instead of the system form in the Default Form field.

With the new formset created, remember to make it available to all navigation schemes which need the ZIP+4 validation. In order to avoid confusion, you can make the default formset member unavailable to those with the new formset.

Pro Tip: I temporarily put “TEST” in the Tab Caption of my custom formset so that I could find it easily when adding it to the navigation schemes.

You now have a separate and customizable Client Demographics formset to play with in your system

Modify Forms to Validate for ZIP+4

We will need to make changes to both of our forms in order to cover all of our bases. Our method for validating is to check the subform zipcode field when it is changed and determine if the zipcode entered is comprised of 10 characters. If the zip code is other than 10 characters, we will alert the user that they must enter a ZIP+4. If they ignore the warning and attempt to save anyway, we will prevent the save and alert them again that a ZIP+4 must be entered.

Custom ‘Client Personal Information’ Form

Step 1) Add a variable to the form just above the Personal Address subform. This variable will be used to store our ZIP code validation state that we will check before saving.
I named my variable is_zip_invalid and gave it a Regular Numeric datatype. You can set your variable to be not visible.

Step 2) Add the following code to the form’s “Before Save Code” property:

if(getFormElement('is_zip_invalid') == '1'){{
alert('You must use ZIP+4');
formValid = false;
}}

The code above checks to see if the value of the variable we just created is ‘1’. If it is, then it gives an alert and tells myEvolv to abort the save because this form is not valid. On the subform, we will add code that will set the value this variable based on what is entered in the zip code fields.

Custom ‘Address by ZIP Code’ Form

Step 1) Add the following code to the ZIP Code field’s “On Change” property:
This code can go under the setAddressFromZip(this); line.

var zip = self.getElementFromXML(currentRowXML, 'zip_code');
if(zip.length != 10){{
window.parent.window.alert('You must use a ZIP+4');
window.parent.setFormElement('is_zip_invalid', 1);
}} else {{
window.parent.setFormElement('is_zip_invalid', 0);
}}

The code above creates a variable named zip and assigns it the value that user enters into the ZIP Code field. The script then checks to see if the value is 10 characters long. If it is not, the code produces an alert to remind the user that a ZIP+4 is required and then sets the value of is_zip_invalid on the parent form to 1. If the value is 10 characters long, the script sets the value of is_zip_invalid on the parent form to 0.

Step 2) Add the following code to the form’s “Before Save Code” property:
Since it is possible for users to open the subform in a new window, we also need to do some validation on the subform itself in case a user ends up adding or editing addresses via this method/

var zip = getFormElement('zip_code');
if(zip.length != 10){{
alert('You must enter a ZIP+4 in order to save');
formValid = false;
}}

The above code does the the same thing that the “Before Save Code” from the other form does. The only difference here is that we have direct access to the value entered in the ZIP code field so we use that to validate the form rather than the variable flag.

When put altogether, you will have a custom Client Demographics formset that will warn users at the time of changing a ZIP code field if they are not entering a ZIP+4 and will not allow saving until the ZIP code is fixed.

One Vulnerability

The way that this is setup, the value of our variable is_zip_invalid is changed any time a zip code is updated so if the last zip code altered is valid, all zip codes will be accepted as valid. So for example, let’s say that I edit two zip codes on the form. On the first one, I only put in the 5-digit ZIP code. I get an alert telling me to use the ZIP+4 and my variable gets assigned a value of ‘1’. Next, I close the alert and alter the second ZIP code and this time I enter the ZIP+4. Our code executes to check that the ZIP code I entered here is valid. It sees that it is and assigns our variable a value of ‘0’. The form will successfully save even though I still have a 5-digit zip in the first address that I edited.

More complicated code might be able to do a more thorough job of validating multiple zip codes before save but I haven’t figured that out yet.

How To: Use a Default Value on a Progress Note

EDIT 8/3/2018: Reader Rosemary asked about using text templates in conjunction with this code rather than including the raw HTML in the JavaScript code. Indeed there is a way to do that, so I have included that method at the bottom of the post. Reviewing the post also exposed that my code had a syntax error so I fixed that. Thank you, Rosemary!

Progress notes in Evolv are system fields in myEvolv that have special properties that make them particularly useful in certain situations. For example, the Progress note field is included in many of the views available to subreports so being able to use the progress note column on a form allows the data contained therein to be fed back on other forms via subreport.

Unlike other form fields, however, you do not add a progress_note field to your form in the form designer. Instead, you add the progress note in the Event Setup area by checking the “Has Single Note” checkbox.

has-single-note-checkbox

Just like with the Service Related Encounter Information that I addressed in another post, checking this checkbox will append fields to your form at the time that the event is launched. Unlike the Service Related Encounter Information, however, there is no way to add the progress note field to your form in the form designer so that you can manipulate its attributes. It is therefore tricky to set a default value for the progress note, but not impossible. The following guide will show how you can use jQuery and the form header attributes to simulate the use of the default value attribute on a progress note field. This can be useful for defaulting in a template when you know only one template would be used and you want decrease the risk that the clinician forgets to apply the template.

How Memo Fields Render

One of the things that makes manipulating a Memo field more difficult in myEvolv is that they are a much more complex field being rendered on the form. With a custom_string type of field, for example, there is just a label/caption and an html input field so you can use some pretty basic javascript to get and set the value of the field or use some of the formfunctions.js functions to get or set the form elements.

Memo fields, on the other hand, have their own menus for manipulating the formatting of the text and spellcheckers, etc. When you are dealing with a Memo field, you are actually dealing with an iframe element that contains a series of div elements that hold those buttons and then finally, buried deep in the iframe you will find a div with the id of “Composition”. That is where the text value of the memo resides.

Further complicating things is the fact that unlike other types of fields that you can easily target by column name, Memo fields must be targeted by their id, which is the GUID that represents their form_lines_id.

Accessing the Text Value of a Memo Field

To target the divelement that contains the text value of your memo field, you must turn to jQuery and use the following code:

var memo_text = $(form_lines_id).contents().find('#Composition').html();

Since the Progress Note field is a system column that has existed for a long time, it has the same form_lines_id in everyone’s system, so to get the memo text of a Progress Note memo field, plug in the form_lines_id:

var memo_text = $('#BFE6BE66-7983-4C3B-8374-1606E7D909A5').contents().find('#Composition').html()

Explanation of Code

var memo_text =
This creates a variable called “memo_text” that will hold the value of the memo field we target.

$('#BFE6BE66-7983-4C3B-8374-1606E7D909A5')
This targets the element on the form that has and id of ‘BFE6BE66-7983-4C3B-8374-1606E7D909A5’, which is the progress note’s iframe. If you want to target a different memo field, you will need to determine the form_lines_id of that field and plug it in here.

.contents()
This gets all of the contents of the iframe targeted above.

.find('#Composition')
This searches the contents above for an element with an id of “Composition”. This is the element that contains the Memo field’s text.

.html()
This gets the html value contained inside the “Composition” div targeted above. We use the html() method because this will preserve the rich text formatting that has been applied to the text in the box.

Setting the Value of the Progress Note

You can set the value of the progress note field with very little changes to the above code. if I want to set the text inside the progress note to “Hello”, I use this code:

$('#BFE6BE66-7983-4C3B-8374-1606E7D909A5').contents().find('#Composition').html('Hello');

Since we are using the html() method, you can insert HTML markup with your text, which is what will allow you to insert a nice template. Remember that you have to escape your >’s and <‘s

Replicating the Default Behavior

Using the code above, we are able to manipulate the text inside the Memo field with On Change and On Click events on the loaded form just fine, but what can we do if we want to default a specific value into the progress note field when the form loads?

We can use the code above to set the value but we need that code to fire AFTER the form has been loaded. Fortunately, there is an attribute on the form called After Load Code that we can use as the trigger for this code.

after-load-form-attribute

But, it’s not as simple as just dropping the code in there because while the code in this field will fire after the form loads, it does not necessarily fire after the memo field iframes are loaded. it is therefore necessary to wrap the code in a javascript setTimeout() function.

setTimeout(function(){$('#BFE6BE66-7983-4C3B-8374-1606E7D909A5').contents().find('#Composition').html('Hello');}, 5000);

The setTimeout() function takes two arguments. The first is the code that you want to execute. In the example above, I wrapped the code into an anonymous function. The second is the number of milliseconds it should wait before executing the code. In my example, I set the timer for 5000 milliseconds or 5 seconds. You can tweak this number as desired to achieve what you want it to do. With this code in place in the After Load Code attribute of the form, 5 seconds after the form loads, ‘Hello’ fills in on the progress note field.

Using A Text Template

You can use a text template in myEvolv to make this all a little easier, especially when it comes to formatting your progress note text. Create your default text in the text templates area of myEvolv.

Then within the setTimeout function, before the line of code that sets the progress note html, add the following line of code:

var myTextTemplate = getDataValue('text_template', 'description', '<text template description>', 'template_text');
where <text template description> is the description you have given your text template (beware of special characters). This line of code will grab your text template, then you can just use the variable you just created in the html() method.

Here’s what the final code would look like if you wanted to use your Incident Narrative text template.

setTimeout(function(){
var myTextTemplate = getDataValue('text_template', 'description', 'Incident Narrative', 'template_text');
$('#BFE6BE66-7983-4C3B-8374-1606E7D909A5').contents().find('#Composition').html(myTextTemplate);
}, 5000);

How To: Prevent Backdated Entries

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;

Tips & Tricks: Remove Unwanted Service Related Encounter Information from Services

I was recently working on configuring an event in myEvolv that required making a custom form in the People Placement and Treatment History form family.  Once I got the form looking right, I set about configuring the event.  I needed this event to be a service so that I could take advantage of the electronic signature functionality so I checked the “Is Service Event” checkbox for the event.

event-config

 

When I added a new service entry to test after saving this configuration, there was now Service Related Encounter Information appended to my form.

service-encounter-info

 

This was a problem since many of these fields were not applicable to the event that I was setting up and I did not want the clinicians to mess with them if they did not need them.  I looked back at the form designer to find out if I could hide them like other fields but they did not show up in the form designer.

form-designer-before

 

Fortunately, there is a way to get around this.  myEvolv automatically adds the Service Related Encounter Fields to your form if the event is a service.  myEvolv also does not allow a form to have the same field on it twice.  Therefore, if you add the fields to your form in form designer, you gain control of the form field properties and myEvolv will not append them to your form again.

As the automatically appended fields indicate, Program Providing Service and Facility Providing Service are required on service events in myEvolv so you do not want to hide these or make them not modifiable or not required. You can still move them around to make your form flow better. The other fields are able to be hidden.

 

Here is a list of the Service Related Encounter Information field column names so that you can add them to your form:

Form Label Event Log Field Column Name
Exempt from Billing do_not_bill
Activity Type activity_type_id
Client Involved is_client_involved
Program Providing Service program_providing_service
Facility Providing Service site_providing_service
Encounter With encounter_with_id
Service Authorization service_authorization_details_id

 

I added those that I wasn’t planning to display to their own Form Group and hid them.  I left the Program Providing Service and Facility Providing Service as they were in order to allow myEvolv to append those to my form automatically.

form-designer-after

 

When I saved the new form design and opened the event, the Service Related Encounter Fields I did not want to use were gone.

service-encounter-info-after

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.