Category: myEvolv Troubleshooting

If you are anything like me, you work with Data Insight by roughing out your SQL query, dropping it into a virtual view, and then starting a report to see if your query is pulling the data you were expecting. If you need to make changes to your virtual view, you return to the virtual view management area of Data Insight and make the changes and hen back to your report to check the results.

Once you have spent many hours working with Data Insight, you will see some pretty strange behavior but one of the most frustrating occurs when you spend a long time troubleshooting a query issue and no changes you make to the virtual view or report seem to make a difference. The report runs in the preview window exactly as it had before.

The Problem

Most of this is speculation but this is what my gut tells me is happening here. With other reporting tools like Crystal Reports or SSRS, you write your query and when it’s time to run the report, the query executes on the database. With Data Insight, you are creating a virtual view that runs when you save the virtual view definition and creates a data object that you then use to write a report.

This might explain why just saving a definition on some more complex SQL can take a while and also why you are limited to using filters on the data you retrieve AFTER retrieval rather than including parameters in your query statement.

The Solution

When you are in the Report Designer, changing the columns used in the report has the effect of refreshing the virtual view that is being used. So after you update your virtual view, reload your saved report, add a column to the report and then remove it before running the report to see your changes reflected in the data that pulls in. Keep in mind that this process will need to be done to all reports that use the virtual view if you want them to update.

I had this issue come up for me recently while working on making placement disruptions more secure. By the nature of placement disruptions, we needed to allow users to go back in and edit the placement disruption to add an end date but we did not want other fields to be editable at that point so I copied the placement disruption forms, made the fields we wanted to lock down not-modifiable and then linked the new forms to the event as the form to use on Edit.

While testing, we noticed that if we saved a new placement disruption and then immediately edited it, the Add form was being used. If we refreshed the list of placement disruptions and then edited the placement disruption, the Edit form was being used as intended. Based on how placement disruptions actually get used, this probably would not be a problem because typically staff will set them up one day and edit them another day, which means that they will have gone through at least one refresh. Still, I was annoyed about this and wanted to figure out how to make it behave. While I used this fix specifically to get the Edit form to be used, you could apply this in any situation where you need the event information to update in the list so that other form functionality works properly as well.

The Problem

I noticed that after saving the placement disruption, the list of placement disruptions did not refresh itself. The most recent placement disruption should be showing at the top of the list but it was being appended at the bottom of the list and the list never refreshed itself to fix the order like it typically does. Also the placement disruption type did not fill in on the list indicating that the list refresh was necessary to update the event information enough to indicate that the edit form should be used on edit instead of the add. A manual refresh made all this happen. So the problem was related to the event listing not refreshing after save.

This is the list of placement disruptions before adding one.After I added a placement disruption, the list did not refresh. The new placement disruption is at the bottom.After clicking the Refresh button, the list updated to fill in missing information and list in the proper order.

The Solution

I went through the formfunctions.js file looking for any code snippet that would refresh the listing after save and found one. If you have any forms that do no automatically refresh the event listing after save, you can add the following code to the After Save Code property of the form:

self.refreshCallerWindow = true;

With this code on the form, after I save the form, the list of event automatically refreshed itself rather than requiring me to click the Refresh button. When I click to edit the newly created placement disruption, the Edit form opened.

With the code on the form, after saving, the list displayed with the proper information filled in and in correct order.

If you have run into the “… is not a valid XSLT or XPath function” error, then chances are that you are messing with the Before Save or After Save properties on a form.

myEvolv uses XML to define forms and XSLT to transform the XML into HTML when displaying the form in the browser. When you export a form from myEvolv, you are downloading an XML document that defines the properties for all of the fields on the form and the form itself that you configured in the form designer. You can then upload that same file to another instance if myEvolv and the system will know how to create that form, generating all of the same fields and properties.

When you go to open a form to enter data, XSLT is used to take the XML ‘recipe’ for the form and convert it into HTML to display in the browser. This presents an issue when you try to store JavaScript code in the Before Save and After Save properties for a form because XSLT has some overlap with special characters in JavaScript and so unless you escape those in your JavaScript code, you XSLT will try to evaluate the code as an XSLT command rather than treat it as JavaScript code to pass along into the HTML.

When I got the error shown below, I was working on a snippet of JavaScript code for the Before Save property that would evaluate whether the start date of the service was before today’s date and if so, update the start date to be today’s date so that no service could be backdated. Part of my code included an if/then statement to check if start date was earlier than today’s date.

Following JavaScript syntax, I wrote my conditionalif(start< today){setFormElement('udf_rx_4_svc_start', todaysDate())};
which caused the above error.

Turns out the problem was the curly brackets { and } because XSLT attempts to evaluate statements inside curly brackets and the XSLT did not contain a todaysDate() function. Luckily, there is a way to escape curly brackets in XML so that XSLT does not try to evaluate them and that is by using double curly brackets. So changing my code toif(start< today){{setFormElement('udf_rx_4_svc_start', todaysDate())}};
did the trick. Error is gone and the form works as expected Before Save.

According to the error message, myEvolv was taking issue with some JavaScript that I was attempting to use to disable/enable a field based on the selected value of a picklist field. Apparently I had an invalid character. After scanning through my code looking for an error in my JavaScript and not finding any, I took a closer look at the error and noticed that it was actually a problem in the form XML that was throwing the error but ti was somehow related to the JavaScript code I had written.

It turns out that the problem relates to the XML standard and special characters. In JavaScript, a double ampersand, &&, is used for the logical operator “and”. In XML, the ampersand is a special character and myEvolv stores form data in XML so when my disable rule JavaScript was being parsed within the XML form document without the ampersands escaped, it caused an invalid character XML error.

To fix this, I just had to switch the && in my JavaScript to &amp;&amp; and the form rendered fine and the JavaScript still worked.

Follow Me

Follow me to receive updates when new posts are created!

Contact Me

If you have a general question or want to request a topic for me to cover in a future blog post, let me know!

Categories

Disclaimer

This blog covers off-script configuration of the myEvolv electronic health record.
Netsmart's official documentation warns against making changes to some of the parts of myEvolv that are covered in this blog's posts. Further, Netsmart support does not cover problems that may arise from customization of myEvolv outside of what their official documentation provides guidance for.
Be advised that implementation of anything contained in this blog has the potential to break your instance of myEvolv and that a fix may require expensive custom work to be performed by Netsmart. Implement at your own risk and test thoroughly in your development environment before implementing in your production environment.