I have been working with Netsmart myAvatar and its ScriptLink feature for many years now. ScriptLink enables organizations to extend the functionality of most forms in the medical record. As with any extension feature, there are significant opportunities to improve or hinder the user’s experience and the overall solution. This means that a robust, mature solution can enhance the gains and minimize the risks.
In a few weeks, I will be starting a series on creating your first ScriptLink API. This series is a result of my efforts in recent years to help reduce the learning curve for new developers, lower the cost for organizations to leverage this feature, and reduce the risk of compromise to the functionality of the application and the user’s experience.
Today’s article is an overview of potential opportunities that I see for both Netsmart and the client organizations that could help accomplish these goals of reduced cost and risk while increasing satisfaction and value. Perhaps we could see some of these start to take shape in 2020 and beyond.
I have separated the opportunities into two groups: For Netsmart and For Client Organizations. Let’s take a look at those for Netsmart first.
These ideas are ones that would require development and/or procedural changes from Netsmart Technologies, Inc. the developer of the myAvatar CareRecord. The opportunity for each is to address the administration, security, and/or utility of the ScriptLink feature. These include:
- Centralized API Management
- Ability to Remove Unused WSDLs
- API Authentication
- Consolidated Reporting
- Performance Logging
- Additional Metadata in the OptionObject
- Identifying the Triggering Event
- Improved Testing and Support Procedures
Centralized API Management
Currently, the connected ScriptLink APIs are managed through the forms they are connected to. This suggestion is to create a dedicated form for managing the list of connected APIs and importing new WSDLs. Ideally, this would be cross module, but I feel a form per module (I.e., PM, CWS, MSO) would be acceptable.
Ability to Remove Unused WSDLs
With this centralized management showing all of the WSDLs that have been imported, it would be nice to be able to remove ones that have been deprecated. This will help administrators avoid selecting the wrong API when configuring a form. Ideally, this would not allow removal if a form is still configured to use it.
Another improvement that the centralized management could allow would be to support securing our API. There a variety of ways to accomplish this. I would suggest an Auth Token at least to begin. We could add that token to the API in myAvatar so it can authenticate with our API. This is especially important when our ScriptLink API is used to make ODBC calls or initiate other actions such as sending emails. This is similar to the SessionToken we already receive to authenticate with myAvatar Web Services.
Currently, reporting against the ScriptLink logging data requires separate reports for each module. I would suggest making each log visible through one of the ODBC connections to allow for a consolidated report on all ScriptLink activity.
In addition to the above, I would suggest making available to the organizations a performance log for the ScriptLink activity. Specifically, this could be used to evaluate the response times of the calls and isolate areas of concern. For example, a ScriptLink request is taking too long to respond. How long is it taking on average and at its worst? Is it time of day related? A specific WSDL, form, or parameter? Is it a networking issue or an application issue?
Additional Metadata in OptionObject
A number of customers over the years have identified some metadata that they would like to add. Here’s a few that I think could be helpful.
- Identify FieldObject that has focus.
- Possibly allow for the setting of focus.
- Identify the FieldType on a FieldObject. This will help to ensure the string FieldValue is properly formatted to convert.
- Identify the FieldLabel. This could be helpful in logging.
Admittedly, the risk with each of these is that it requires changes to the FieldObject which can impact backwards compatibility. We would likely end up with 2020 versions of each object to avoid that issue.
Identify the Triggering Event
It would also be able to provide to the API the event that triggered the call without having to manually identify in the parameter. These current events that I am aware of include:
- OnLoad (Form)
- PreFile (Form)
- PostFile (Form)
- OnLostFocus (Field)
- OnClick (Button)
For both OnLostFocus and OnClick, it would also be helpful to know which object lost focus or was clicked.
Improved Testing and Support Procedures
Lastly, it would be helpful to improve the testing and support procedures to help clearly identify which side of the connection a regression exists on. Netsmart should hold no responsibility for regressions in the ScriptLink API code. However, we should be able to clearly demonstrate when there is a regression on the myAvatar side.
For example, I once identified that I could not add a new RowObject to a section of the Open Incident form. The same code could successfully add a new RowObject to a modeled form with a multiple iteration table. The issue was on the myAvatar side and I suspect it had something to do with there being more than one multiple iteration table on the form.
One solution for this could be adding the returned OptionObject to logging specifically for validation. If the OptionObject passes validation then the issue will be with the how the form processed the OptionObject. Otherwise, if the OptionObject fails validation then it is with the external application.
For The Client Organization
Ok. Now for the client organizations. if your organization utilizes or are considering utilization of the ScriptLink feature this section is for you. Many of these suggestions are applicable to the Avatar Web Services feature as well. While there are a number of recommendations that could be made for any development effort, these are based on common gaps that can exist in ScriptLink implementations.
- Use a Code Repository
- Use Unit Tests
- Add Logging
- Create Distinct Environments
- Use a Modern Deployment Model
Use a Code Repository
This one is surprisingly easy to overlook in various implementations, yet incredibly easy to accomplish. Using a code repository helps for disaster recovery, managing and responding to regressions, and can be integrated into deployment solutions. I recommend Azure DevOps and GitHub. Both are free to use for small teams, however GitHub for organizations is only free for public repositories. I will cover both of these options in future articles.
Use Unit Tests
A better title for this recommendation might be, “Write testable code.” Unit tests are helpful for writing clean and testable code. This enables you to minimize regressions and defects in your code due to changes and enhancements. When I started writing Unit Tests for my ScriptLink API, I uncovered a number of bugs just waiting to disrupt our users and as a results reduced the number of support desk requests submitted due to coding errors.
There are a number of logging options out there. In the .NET world, I like the NLog solution. By generating your own log entries you are able to improve root cause analysis and reduce time to release fixes. I also found how inadequate my log entries can be and then iterate on that to improve future troubleshooting. Be careful where you place your logs, how you secure them, and what you put in them as these logs could become a security and/or privacy concern.
Create Distinct Environments
There is a joke out there, “I don’t always test my code, but when I do, I test in Production.” The joke works because each of us at some point have tested a code or configuration change in a Production environment. I recommend setting up a distinct development, test/staging, and production environments. Ideally, even the test environment would be on a separate web server than production so you can test changes to the web server itself before affecting production.
Use a Modern Deployment Model
If you are still uploading files via FTP or making changes directly on the web server it is time stop. There is even a controversial push to move away from using Web Deploy in .NET solutions (a.k.a., Right-click Publish), however it is a great place to start if you or your organization is just getting started. Most of us now have Continuous Integration and Continuous Deployment solutions available to us to automate our testing and deployment, including to premises servers. One such example is Azure Pipelines.
What Do You Think?
While there are ideas for Netsmart to consider, the ideas for the client organizations can be implemented today. Perhaps 2020 is a good year to focus on the testing of your code. I found with those in place it became easier to make changes later. Perhaps it is time to consider these for your organization?
Please note that these ideas do not include anything related to a potential myAvatar change to utilize REST APIs. This is an intentional choice as if/when this change occurs there could be a number of other changes that come with it that I cannot anticipate today. However, write testable code would make the transition to REST much easier in the future.
So, what do you think? These are just a few of my ideas. What are some of yours?