How To: Create an Events to Complete Subreport

January 18, 2018August 28, 2018 Dean Leave a comment

EDIT 3/16/2018: Reader Jen G. pointed out that a staff member’s staff_id != people_id in all cases and therefore my approach would not always work for all staff. She proposed a different form to copy for this setup that will work 100% of the time so I have updated the post to reflect her proposed changes and fix my approach. Thank you, Jen!

This comes from a reader request. The goal was to create a subreport in the Agency > Staff & Security > Staff Information formset that would list the service events that a selected staff member had not fully completed. The subreport could be useful for supervisors to follow up on events that their supervisees needed to e-sign or otherwise complete, especially in the event where a staff member was transitioning out of the agency. The following is my proposed solution to that problem:

Step One: Create a User Sub Report

Navigate to Setup > User Tools > Sub Reports – User > User Sub Reports and create a new User Sub Report. Give the sub report whatever name and code you wish. For System Sub Report, select any report that has event_view as a Data Source Name. In my case, I chose the “Compass (Initial) Peer Delivered Services” report.

When you are selecting from this list, the only critical thing is the data source name. Everything else only speaks to how that particular report had been configured with the data source for that particular system report. It will tell you which columns were used to join and the remarks column will give you and idea of how it might be used “out of the box” but you can change all of those properties once you have the data source linked to your user sub report.

On your new sub report, change the following properties:

SQL Code: is_service_event = 1 AND is_locked = 0

This will filter the event log to only show events that are service event and only those that are not locked. The event_view has many columns in it that will allow you to customize this filtering to get exactly what you want to see. Some other options are: completed, is_amended, is_billed, is_deleted, is_e_signed, is_final

Report Fields: Pick any that you want to display. For my subreport, I wanted to show the client (full_name), the event (event_name), and the date of the event (actual_date).

The one that you need to have for sure is staff_id, which we will mark as a join column. In the Overwrite Form Field to Join, put some value (I used “staff”) and for the operator, choose “Equal”. Remember the Form Field to Join that you used for later. Below is a screenshot of my setup:

Step Two: Create Form

You don’t have to create a whole new form to house this subreport. You might choose to add the subreport to one of the already existing forms in the Staff Information formset. The important thing for this step is that the form you end up putting this subreport on MUST have the staff’s ~~people_id~~ staff_id on it. Maybe the form already has it on there or maybe you need to add it in the form of a variable. I will show you how to add it if it doesn’t already exist.

In my case, I am adding the subform to a custom version of the Personal Info formset member. So in form designer, under the Personal Information form family, I copied the Staff Personal Information Form. On my custom form, I hid all of the fields that I did not want users to see and I added the subreport that I created in part one. Now I need to make sure there is a staff_id named “staff” for the subreport to join on.

To do this, add a regular string variable to the form. Caption it whatever you want but give the variable name the same name as your used for your Overwrite Form Field to Join on the subreport created above. We need this variable to default in with the staff member you select’s staff_id so in the default value field, we will put the following code:

~~keyValue~~

Edit: Because I used a form from the Personal Information form family, the keyValue in this case will be a people_id and not a staff_id. Therefore it will only work right on those staff who have the same value for their staff_id as they do for their people_id and this is not always the case. If you copy a form from the Staff form family, you can simply use keyValue because it is the staff_id. But if you are copying a Personal Information form, use the following code to get the staff_id:

getDataValue('staff', 'people_id', keyValue, 'staff_id');

Here is a screenshot of my variable’s configuration:

Once you have confirmed that this field is pulling in a GUID, you can make this field invisible on the form.

Step Three: Create a New Formset Member

With your new form created, you can now associate it with a new formset member so that you can display it for users.

Navigate to Setup > User Tools > Formset Maintenance > FormSet Members and select the Staff Information Formset from the Agency module.

Create a new formset member, name it what you’d like and then select the Personal Information form Family and your new form as the Default Form. Make sure Is Active is checked and then save. Remember to go through the Navigation scheme setup and turn on the new formset for the users who will need access.

The Final Product

With everything setup above, you can navigate to your new formset member and select a staff member. Your form variable should get a default value of the staff you selected’s staff_id and your sub report should be joining on the that staff_id, thereby filtering the event_view to that staff member’s events. Your SQL Code statement on the user sub report will further filter the event_view to just those you are interested in seeing. In our case, the service events that are not locked.

How To: Add Additional Links to Formsets on a Form

November 23, 2016November 23, 2016 Dean Leave a comment

When you setup a service form in myEvolv, the Link to Person is usually setup in such a way as to make the name display as a link on the form. Users can then click the link and it will take them to a formset where they can look up additional information about the client or complete additional tasks related to the client.

link-to-person

There may be times when you want to add more than one link to a formset on a single form.

If you look at the Link to Person field in the form designer, you will see most of the setup that is required to create these links.

link-to-person-properties

Here, the people_id column is used to get the GUID for the client. Instead of just displaying that GUID, the All People Table is associated with the field. That renders the client’s name instead of the GUID. Then the Client Information Screen is used as the Formset to call. That renders the name as a link that opens the Client Information Screen when clicked.

Setting up another link might seem to be as easy as copying this setup on another field, but you quickly run into a couple hurdles that must be cleared.

Duplicate Fields

You cannot have the people_id column on your form twice so you need another way to add a link to the individual. Fortunately, myEvolv has a way to work around this using variables.

Variables are useful in this situation because we do not need the data stored in it to be saved to the database. We just want to hold some data while the form is rendered in the browser that will allow us to create the link and use it. We could go about this by creating a user-defined field that would be of foreign-key type and store a duplicate people_id GUID, but that would be overkill just to generate the link and clutter the database with redundant information.

When you create your variable, you can set it up similar to how you would set up a user-defined field.

In this case, you want the Data Type to be Foreign Key ID. You can use the All People Table as your Look-Up Table Used. Finally, you can choose the different Formset that you wish to call from this link to the person.

second-link-to-person-variable-properties-1

Default Value

If you saved your form at this point and tried it out, you would notice that your new variable field is empty and if you left it modifiable, you would need to select your client to get the link. That’s because we need to give the variable a default value.

The people_id field has some automatic default value functionality based on the fact that you are entering the event from a client’s record. myEvolv is setup to default some fields automatically based on the service track information – things like client, program and facility will fill in automatically when entering services from the Service Entry area because based on which program band and the client’s facility placement information, myEvolv is able to determine what the default value should be.

Our variable, on the other hand, has no such built-in functionality and so we must explicitly provide it with a default value to pre-populate.

To provide a default value in this case, simply put parentValue in the Default Value property of the variable. parentValue is equal to the selected client’s GUID and it is the value that people_id uses behind the scenes to pre-populate itself.

Now when you open your form from service entry, it should look something like this:

second-link-to-person

Each link to person opens a different formset.

How To: Create a Custom Formset Member that Shows Only Active Diagnoses

July 11, 2016July 11, 2016 Dean 1 Comment

My agency has a program that requires that clients have a script for service on file in order for services to be billable. Since a script for service requires a diagnosis, we configured the program’s services to require an active diagnosis in order to generate a claim. As a result, we have client diagnoses expiring on the same date as the script for service. When a client gets a new script for service, the same diagnosis is re-entered with a new start and end date. After a few years enrolled in this program, a client’s diagnosis screen begins to get cluttered with inactive diagnoses so our clinicians asked for a way to just see the current diagnoses that were on file rather than all of the diagnoses that had been entered for the client over the years.

myEvolv includes as “Diagnosis – Active” formset member that looks like it was created to serve exactly this function but it would not list any diagnoses that have end dates on them (even future end dates). Our program’s diagnoses are entered with end dates since we need them to expire at the same time as the script for service. We were able to get what we wanted by creating a custom formset that uses a custom default form with a modified list condition. I have outlined the steps we took to accomplish this for our specific scenario but you could apply this in other situations where you want to customize the listing in a formset member.

Step 1: Create a New Default Form for Active Diagnoses

myEvolv’s Active Diagnosis formset member used the “Diagnosis form for listing – active only” form as its default form so we used it as the basis for our new form.

In the form designer, open the “Diagnosis Information” form family.

Right-click to copy the “Diagnosis form for listing – active only”. Give the new form a name and code. Ours is called “Active Dx for MyEvolv Launcher”

Step 2: Modify the List Condition

In the new form’s header properties, edit the “List Condition Property”

list-condition-edit

Change the list condition code as shown below

list-condition-code

Explanation of Code and the List Condition Property

myEvolv’s code: event_log.end_date is null and event_log.is_deleted = 0

The List Condition property allows you to use SQL statements to manipulate the data that will be listed on the formset member. Anything you put in the list condition property will be executed as though it is part of the “WHERE” clause on a SQL query. In the code above, you can see that myEvolv’s list condition was designed to only list diagnoses that have no end_date and have not been deleted.

We adjusted the list condition to also show us diagnoses with end_dates in the future so I modified the code to:

(event_log.end_date IS NULL OR event_log.end_date > GETDATE()) AND event_log.is_deleted = 0

I used SQL’s GETDATE() function to get today’s date so now in order for the diagnosis to list, it must either have no end_date or an end_date that is greater than today’s date and not have been deleted.

Step 3: Create a Custom Formset Member

We now need a place to apply the new form we created in myEvolv so that it can be used. We could just swap put the form for the myEvolv-supplied active diagnosis formset member but since other programs might be using it, we decided to create a custom formset member that was only visible to the clinicians in this program. Our clinicians use myEvolv Launcher as their home pages in myEvolv. They are used to clicking on their clients from the My Client’s widget, which launches the My Client Information standalone formset so that is where we wanted to add our custom formset.

Go to Setup > User Tools > Formset Maintenance > FormSet Members and select the ‘My Client Information’ FormSet (it is in the “My Evolv” module)

Create a New “Formset Member – User Defined”.

list-condition-formset-member-setup

You can give the tab any caption or description you would like. Because we are working with the Diagnoses, we have to pick “Diagnosis” for the Event Category that will allow us to pick the “Diagnosis Information” form family and our default form, “Active Dx for MyEvolv Launcher”.

NB: Once this is setup, remember to give users access to the new form in the Navigation Access Setup. In this example, the new formset member is listed in the My Evolv Module -> My Client Information section.

Results

The screenshots below were taken on 7/11/2016 so active diagnoses would be those that have no end date or an and date after 7/11/2016.

diagnoses-all

This is the generic “Diagnosis Information” formset member. It is showing all of the diagnoses (except those that have been deleted) for the client. You can see that the first two would be active by our program’s definition since we have one with a future end date and one with no end date. The other three are expired diagnoses and those are the ones that we do not wish to display in our custom formset member.

diagnosis-filtered-poorly

This is myEvolv’s “Diagnosis – Active” formset member. It is only listing the active diagnosis that has no end date.

diagnoses-active

This is our “Script for Service – Active Only” formset member. Both active diagnoses are listed. Success!

List Condition Overwrite on Upgrade?

We have noticed that the list condition on this formset member has been overwritten after upgrading our system. We have a support case about the phenomenon and hopefully it will be resolved in a future release but until then, beware and be sure to save a backup of your custom list condition code to re-apply after upgrades.