Users may notice a slight change to the way versions are labeled in a variety of places, such as the Log In screen and Help/About screen. 

This breaks down as follows:  <CEHRT version>.<2 digit year>.<1 digit major>.<1-2 digit minor>.<1-2 digit patch> (build number).  The build number may be useful for troubleshooting. 

In some markets, customers use inactive practices to specify portal configurations.  When an order is submitted on these portals, the system assigns the order to that inactive practice.  However, orders associated with inactive practices are not displayed on worklists within RIS or on the portal, which makes them invisible to imaging center staff and the referring provider.

To accommodate for this, it is now possible to assign an active practice to associate with these orders. 

In the Portal Configuration Overrides list, a new option for SaveAsOrderPractice has been added.  The Practice Code for the desired practice should be entered here. 

It is also possible to configure this at the applicationsettings.config level. 

If the configuration is not specified, the system falls back to the Imaging Group practice.

eRAD RIS support staff sometimes need to update data in the RIS via SQL.  Prior to the worklist performance enhancements in version 2018.1, it was possible to change any column in a RIS database table via SQL and an order/study would automatically be added to or removed from a worklist and/or the new column value would be reflected in the worklist because RIS determined the worklist contents at the time of query.

In RIS version 2018.1 and later, updating any field in the database will NOT be reflected in the worklist.  This is because worklist contents are now determined at time of save via the RIS Services (i.e. not in the database).  The tools originally provided to assist with this change require the support team to know which worklists should be updated as a result of a changed data value.  This feature provides the ability for RIS to handle the determination of which worklists to update with new data or items to add or remove. 

To this end, two new database stored procedures have been created:  “c_WL2_Evaluate” (single item) and “c_WL2_EvaluateList” (multiple items).  These stored procedures will trigger a re-evaluation of the worklist rules for a single order/study or for a list of orders/studies.  In addition, worklist flags will be re-calculated when the support team updates RIS data via SQL. 

The c_WL2_Evaluate stored procedure is an implementation that builds a list of one order/study and calls c_WL2_EvaluateList with this single item in the list.  This provides a quicker way for the support team to trigger a re-evaluation for an order/study without having to build a table variable and populate a list.

When executed, these stored procedures will populate the c_async_job and c_async_job_config tables using a job type of “WorklistEvaluation.”  The RIS Services have been updated to poll for the “WorklistEvaluation” job type. When jobs are found, the RIS Services will retrieve a study container for each job (order/study) and run a set of worklist evaluation rules.  Then it will add or remove items to or from a collection of worklists.  No audit entries or action messages are created and no counters are updated. 

After calling one of these stored procedures, it may take a few seconds or more for the RIS Services to re-evaluate the worklist rules and/or re-evaluate the worklist flags, depending on the number of items to update.

Here is the signature and description of each SP:

<code class="sql">
[c_WL2_Evaluate](@order_key int, @study_key int, @last_updated_by_user_id varchar(100), @table_column_list varchar(4000)=null, @wl_flag_list varchar(4000)=null)

  /* [c_WL2_Evaluate] is to trigger evaluation of order or study to be added, updated or removed from worklists,

based on worklist business rules.

       Arguement:
           @order_key: the value of the order_key to be added, updated or removed from a WL.

           @study_key: the value of the study_key to be added, updated or removed from a WL.

           @last_updated_by_user_id:  the value of the user id of the person making the update.  Can also be free text like 'RISSupport'.

           @table_column_list: A comma seperated list of table_name.column_name, e.g. "c_study.status_code,c_study.ready_to_read_flag"
                               When populated, only rules affected by tables and columns in this list will be executed.
                               An * and nothing else will run all WL Rules.
                               When empty, no WL rules will be evaluated for this order or study.

           @wl_flag_list:  A comma separated list of Flags that are also to be recalculated.
                           When empty, no WL flags will be recalculated.
                           An * and nothing else will recalculate all WL Flags.
  */
</code>

<code class="sql">
[c_WL2_EvaluateList](@WLOrderStudyKeyList c_type_OrderStudyKey_list readonly, @last_updated_by_user_id varchar(100), @table_column_list varchar(4000)=null, @wl_flag_list varchar(4000)=null) as

  /* [c_WL2_EvaluateList] is to trigger evaluation of order or study to be added, updated or removed from WL,

based on WL business rules.

       Arguement:
         @WLOrderStudyKeyList:  a table variable of type "c_type_WLEvaluation_list" that contains a list of

orders/studies.  The columns for this table variable are:
                                _order_key: the value of the order_key to be added, updated or removed from a WL.
                                _study_key: the value of the study_key to be added, updated or removed from a WL.

         @table_column_list: A comma seperated list of table_name.column_name, e.g. "c_study.status_code,c_study.ready_to_read_flag"
                             When populated, only rules affected by tables and columns in this list will be executed.
                             An * and nothing else will run all WL Rules.
                             When empty, no WL rules will be evaluated for this order or study.

         @wl_flag_list:  A comma separated list of Flags that are also to be recalculated.
                         When empty, no WL flags will be recalculated.
                         An * and nothing else will recalculate all WL Flags.

         @last_updated_by_user_id:  the value of the user id of the person making the update.  Can also be free text

like 'RISSupport'
  */

</code>

A new version of the ImaginePay API has been created to include new fields for information related to the patient’s pre-existing balance.  The purpose of the changes is to make it possible to appropriately allocate the portion of the payment that is related to the pre-existing balance immediately, instead of holding those funds until the current study’s charges are processed.

Endpoint: “paymentrequest/new”
New Fields: PriorBalance, BillingPatientID, BillingIdentifier

The new fields are optional, so the API is backwards compatible.