durations – CorbiNet Blog

Many programs bill for units that are calculated based on duration. For example, programs may bill where 1 unit = 15 minutes of service time. The myEvolv Finance module handles those calculations to generate an accurate claim based on the duration entered in the service documentation but there may be times when you would like the calculated units to display on the form itself. There are no system form fields that do this for you but you can calculate the value with JavaScript and put it into a custom string field for display on the form.

calculated-units-form-fields

Duration Fields

The first step is to obtain the value in the duration field and we want to do this every time the duration changes on the form so in the On Change code for the duration field, we will use the following code:

var dur = getFormElement('duration');

Duration fields have masked inputs. When you put in ’30’, the myEvolv converts that to 00:30. When you put in ’90’, myEvolv converts it to 01:30. Therefore when you go to retrieve the value in the field, you are given an HH:MM string. The first task in calculating units is to convert this value back to an integer representing the number of minutes.

Split the String

We know the mask for the time is HH:MM so all we need to do is break the string into hours and minutes. We can do this using JavaScript’s split method:

var a = dur.split(':');

Here we have created a new variable that is an array containing hours and minutes. If the initial input was ’02:45′, a is now equal to an array that looks like this:

('2', '45')

Calculate Minutes

Now we have to perform a little math to get the number of minutes.

var mins = (+a[0] * 60 + (+a[1]));

Here, we take the hours in a and multiply that by 60 to get the number of minutes and then add it to the minutes in a. The ‘+’ signs tell JavaScript to cast the values in the array as numerical values so that math can be performed on them. Remember that the value we got from the duration field was a string.

Calculate Units

For the sake of this example, we will use 15 minutes = 1 unit. We simply need to divide mins by the number of minutes that makes 1 unit to get the number of units. However, there is one tricky bit. Often these billing scenarios do not allow for the billing of partial units. That means if the duration is ’00:35′, we want to calculate 2 units, not 2.333333333 units. So in addition to the division, we will also use JavaScript’s Math.floor method so that partial units are rounded down to the nearest whole.

var units = Math.floor(mins / 15);

If you need to calculate a different unit formula, you can do that by changing the number of minutes. For 1 hour = 1 unit, you just make the ’15’ into a ’60’.

Set the Units Value

Finally, we just need to put the calculated units into our units field. I am using a custom string type field.

setFormElement('udf_calculated_units', units);

With this code in place for the On Change event on the duration field, the correct number of units should calculate into the udf_calculated_units field whenever the duration value changes.

Full Code Block

var dur = getFormElement('duration');
var a = dur.split(':');
var mins = (+a[0] * 60 + (+a[1]));
var units = Math.floor(mins / 15);
setFormElement('udf_calculated_units', units);

Last Updated: August 23rd, 2016

When you are configuring forms in myEvolv, it can be tricky determining how to handle dates and times. Different myEvolv date and time fields are used within the system in different ways. Some of the implications of using one EventLog date or time field over another might not be apparent until the form has been in use for a while, at which point it might be too late.

This post will be an attempt to layout everything I figure out about the way the various EventLog date and time fields work in myEvolv to aid in making a more informed choice about which to include on forms.

Date and Time Columns Available in the EventLog

As of v9.0.6994.136, the EventLog table contains the following date and time columns:
You can click a column caption to skip down to the details for that column

Caption	Column	DataType
Actual Date	`actual_date`	DateTime
Amended Date	`amended_dt_tm`	DateTime
Approval Date Internal QI/MIS	`approved_qi_date`	Date Only
Approval External Date	`approved_external_date`	Date Only
Approved Date	`approved_date`	Date Only
Date Entered	`date_entered`	DateTime Updated
Date Locked	`date_locked`	DateTime
Date timestamp timesheet was submitted	`date_submitted`	DateTime
End date	`end_date`	DateTime
Expiration Date	`expiration_date`	Date Only
Final Approval Date	`final_approval_date`	Date Only
Proc Discontinued Date	`proc_discontinued_date`	DateTime
Procedure Completion Date	`proc_completed_date`	DateTime
Reconciliation Date	`reconciliation_date`	DateTime
Target End Date	`target_end_date`	Date Only
Verified Date	`verified_date`	DateTime
Duration	`duration`	Time Duration
Duration Other	`duration_other`	Time Duration
Planning Time	`planning_time`	Time Duration
Travel Time	`travel_time`	Time Duration

DataTypes and Display Code Type

Date and Time data can be displayed and captured in a few different ways on forms depending on the Display Type Code that is indicated in the form field’s properties

DateTime		Displays a date field and a time field
Date Only		Displays a date field with no time field
Time		Displays a time field with no date field
Time Duration		Displays a time duration field

Default Display Code Type

In the form designer, the default Display Code Type is based on the DataType of the column:

If you select a DateTime column, the Display Type Code will default to DateTime
If you select a Date Only column, the Display Type Code will default to Date Only
If you select a DateTime Updated column, the Display Type Code will default to DateTime
If you select a Time Duration field, the Display Type Code will default to Time Duration
If you select a Time Only field, the Display Type Code will default to Time (there are currently no Time Only columns in the EventLog table but you may wish to create a user-defined field column of this type so it is included here)

Changing Display Code Type

In some cases, you can change the display type for the field.

You CAN use a Date Only Display Code Type on DateTime and DateTime Updated columns
- This will allow you to display or capture dates without a time when you want to use one of the DateTime columns.
- When a DateTime column is captured using Date Only Display Code Type, the time will be inserted into the database as 00:00 AM
  - This has implications for service overlaps – multiple services with no captured specific time for a client in a single day will have the same time

You CAN* use a Time Display Code Type on DateTime and DateTime Updated columns
- *myEvolv will not prevent you from saving a form with a field setup this way, however it is not terribly useful (see below)
- This will allow you to capture times without a date, however it will display a date/time string.
- When a DateTime column is captured using Time Display Code Type, the date will be inserted into the database as 1/1/1900

You CANNOT use a DateTime Display Type Code on a Date Only column
- Date Only columns do not have a corresponding _tzo column in the database to store the time value that you are capturing on the form. Upon attempting to save, you will receive an error that will prevent the save.

It is UNKNOWN whether you can use a DateTime Display Type Code on a Time Only column
- I will investigate this soon.

You CAN use a Time Display Type Code on a Time Duration column
- This will allow you to capture a time without needing a date value.
- This may have unforseen consequences elsewhere in myEvolv since the system expects this data to represent a duration, not a timestamp — requires more investigation

Individual Column Details

Actual Date | `actual_date`

The actual_date is an important date field in the EventLog when it comes to events. It is meant to represent the actual date and time that an event occurred.

Where else is it used?

It is the date and time that displays in the Service Entry listing in the “Actual Date-Time” column
service-entry-actual-date

The actual date also displays in the Treatment Plans listing in the “Start Date” column
plan-development-actual-date

The actual_date appears in the “Actual Date” column in the Service/Case notes & Planning Approval area of myEvolv. It is displayed as Date Only
actual-date-supervisor-module

Service Overlaps

myEvolv does not allow service events of the same type to overlap for a client. Therefore if you are setting up an event that could occur multiple times in a single day, you must display the actual_date as a DateTime field on the form and have clinicians input a time. If you display the actual_date as Date Only, all services will be put into the database at 00:00 AM and myEvolv is prevent the second service of the same type from saving because of an overlap. If you do not wish to have the time displayed on the events after the initial entry, you could use a different “Edit Form” in the event configuration which displays the actual_date as Date Only.

service-overlap-error

Amended Date | `amended_dt_tm`

Approved Date Internal QI/MIS | `approved_qi_date`

Approval External Date | `approved_external_date`

Approved Date | `approved_date`

The approved_date appears in the “Approved Date” column in the Service/Case notes & Planning Approval area of myEvolv. It is displayed as Date Only
approved-date-supervisor-module

Date Entered | `date_entered`

The date_entered column is used by myEvolv to store a timestamp for when an event is first saved in the system.

This column is displayed on the Clients Services & Treatment canned reports, which show both the actual_date that clinician’s enter on their services and the entered_date that the system generates so that supervisors can check for contemporaneity of entries.

The difference between the entered_date and the actual_date is used to determine if a service has been documented contemporaneously based on the contemporaneous rule defined in the billing setups and when running a Contemporaneous Rule Report canned report.

Since this column is intended to store system-generated timestamps, it is not recommended that you add this field to a form except in the case that you would like to display the date and time that an entry was entered into the system by a clinician. In this case, the field should be made not-modifiable.

Where else is it used?

The date_entered appears in the “Entry Information” column in the Service/Case notes & Planning Approval area of myEvolv.
date-entered-supervisor-module

Date Locked | `date_locked`

The date_locked column is used by myEvolv to store a timestamp for when a service is last e-signed by the entering clinician this locking the event from being edited.

The system generates the timestamp when a service event is electronically signed which can occur in three circumstances:

Upon saving a service if the service is configured to “Auto-Submit/Sign”. In this case, the date_locked column will have the same timestamp as the date_entered column.
Upon clicking the “Electronically Sign” button if the service is configured for “Electronically Signed”
Upon clicking the “Submit” button if the service is configured for “Can Submit”

If a clinician clicks the “Remove Electronic Signature” button on an electronically signed service, the date_locked column will become NULL.

Since this column is intended to store system-generated timestamps, it is not recommended that you add this field to a form. The date_locked will display on electronically-signed services automatically (see below).

Where else is it used?

The date_locked displays as the “Date” with the signature image on electronically signed
locked-date-sig-image

and submitted services for the “Signed by” signatures
locked-date-sig-image-approved

[the “Date” for the “Approved by” signatures come from the approved_date column]

The date_locked appears in the “Submission Date” column in the Service/Case notes & Planning Approval area of myEvolv. It is displayed as Date Only
locked-date-supervisor-module

Date timestamp timesheet was submitted | `date_submitted`

End date | `end_date`

Expiration Date | `expiration_date`

The expiration_date column is intended to be used to indicate the expiration date of a treatment plan in myEvolv.

Where else is it used?

The expiration_date appears in the “Expiration Date” column in the Plan Development area of myEvolv.
expiration-date-plan-development

Final Approval Date | `final_approval_date`

The final_approval_date column is used by myEvolv to store a timestamp for when the final step of a route has been completed.

Since this column is intended to store system-generated timestamps, it is not recommended that you add this field to a form. The final_approval_date will display in the Routing History of routed treatment plans.

Where else is it used?

The final_approval_date appears in the “Final Approval Date” column in the Plan Development area of myEvolv.
final-approval-date-treatment-plans

Tag: durations

How To: Calculate Units Based on Duration

Duration Fields

Split the String

Calculate Minutes

Calculate Units