In eRAD RIS version 2018.1, a new feature was added to change the criteria that determine the type of Reminder that will be generated based on the BI-RADS code (see Feature 16359 for details).  In addition to making those changes, eRAD RIS has a new option that will allow for an administrator to configure an exception for a specific Recommendation.  It is now possible to set a Reminder Type Override option for a Recommendation when needed. 

In the Recommendation table, a new column is available, named Reminder Type Override.  To configure an override, the administrator will select one of the three Reminder Types in this column:  Reminder—Routine, Reminder—Callback, or Reminder—Short Term.  It is only necessary to complete this field when there is a desire to treat the Recommendation differently.

For example, if a Recommendation is available for BI-RADS 3 that should always occur immediately (instead of a short-term follow-up), setting the Reminder Type Override to Reminder—Callback will result in the Reminder being labeled as Reminder—Callback, even if the radiologist has selected BI-RADS 3 (which would result in a Reminder—Short Term under normal circumstances). 

When a report with a Recommendation is signed, RIS will check to see whether the Recommendation has a Reminder Type Override.  If so, that will be used.  If not, the default Reminder Type will be used according to normal workflow. 

Important note: 

As usual, if the Follow Up Days is blank for the Recommendation, a Reminder will not be generated.  Adding a Reminder Type Override will not result in creating a Reminder if the other necessary configuration has not been completed.  Reminders need to have a Target Date, which cannot be calculated if the Follow Up Days value is blank.  This value should only be blank for Recommendations that should not generate a Reminder.

In eRAD RIS version 2018.1, a feature was added that made it possible to change the procedure on an EMR order to an internal procedure code and save that change while keeping the Ordered status.  Unfortunately, this change did not result in the desired end result, which was for the workflow for the internal procedure code to proceed as usual (e.g. UM workflow and configured RADAR contact workflow).  This feature extends those changes to treat the updated order as if it were generated in the RIS, despite having been created via an EMR.  Aside from maintaining the appropriate connections back to the EMR, all usual downstream processes will be in effect after the internal procedure is selected.

When the procedure has been changed from an EMR procedure to an internal RIS procedure, the following things will be true:

·         The order will maintain its important EMR characteristics (e.g. External Order #, Issuer of External Order #, the EMR Procedure Description)

·         The RIS-procedure code will be saved and this internal code will drive other workflows, such as UM. 

·         The description that matches the internal RIS code is what will be displayed on any worklists.

·         Any downstream workflows that are driven by the RIS procedure code will occur as usual.

·         When the report is eventually signed, it will flow back to the originating EMR as usual.

When a new user is created within the Admin Tool an email is required.  When the new user logs in for the first time, they may choose to change the email, which will generate a verification code to be emailed.  Previously, the verification code was sent to the original email that was used for account creation.

For ease of use and to properly validate the correct email has been entered, some changes have been made to the account creation process when completed via the Admin Tool.  First, the email address is no longer a required field when the account is created via the tool.  It will continue to be marked as a required field, but it will not be enforced until the end user’s first log in.  At this time, the user will be required to enter their own email.

If the admin did enter an email address when creating the account in the Admin Tool, this email will be replaced if the user chooses to update it and the verification code will be sent to the new email address to properly validate it. 

The “Linked Studies” feature in eRAD RIS allows multiple studies from the same order be grouped and later read by the radiologist as a single diagnostic report.  The ability to view the linked collection and report was supported by the RIS portals, but it was only possible to view the images from the primary study.  In addition, the primary study was not always the first study in the list adding to confusion.

The Provider and Patient Portals now support the ability to view the images from all studies in the linked collection.  To support this, the following changes were made to the patient folder screen:  First, the primary study will always be shown as the first study in the order, and second the linked studies will be shown indented below the primary study.  Selecting a secondary study will allow the images to be displayed for the secondary study.

eRAD RIS now supports a PACS integration with Siemens Syngo Plaza.   This integration follows the standard PACS integration methodology of using a plug-in.  

Configuration:

Configure the PACS lookup with the type of SYNGOPLAZA:

In the Config column of PACS lookup, configure the integration as appropriate.  An example and description of each field is shown below:

<SyngoPlazaConfig>

  <UseRISCredentials>false</UseRISCredentials>

  <SingleSignOn>false</SingleSignOn>

  <OpenStudyUsing>ACCN</OpenStudyUsing><!--PSUID, SSUID, PATID_ACCN, ACCN -->

  <PACSDomain>PACS</PACSDomain>

  <CloseAction>ApplicationDefault</CloseAction> <!--  ApplicationDefault, SaveImagesWithoutPrompting, DiscardChanges, SaveImagesWithPrompt-->

  <LoadFlaggedImages>All</LoadFlaggedImages> <!-- All, Flag1, Flag2, Both -->

  <LoadPriorType></LoadPriorType> <!-- Related, Exact, All -->

  <LoadOnlyTopJ>false</LoadOnlyTopJ>

</SyngoPlazaConfig>

<!--

Configuration options:

Single Sign On – optional setting - If enabled the current windows credentials are passed to the integration.  The user must have the Syngo Plaza role “syngo.plaza_single_signon”. 

OpenStudyUsing – Determines what parameter is used to launch the study.  Options are:  PSUID, SSUID, PATID_ACCN, ACCN

PACSDomain - If there are multiple domains in Syngo Plaza, the domain needs to be configured here so that it is passed to the integration.

CloseAction – Determines what action is taken when the study is closed in RIS.

LoadFlaggedImages – A Syngo Plaza set of options:

  * All - (default) Load all images, independent of flagging.

  * Flag1 - load images that are flagged with "Flag1"

  * Flag2 - load images that are flagged with "Flag2"

  * Both - load images that are flagged with "Flag1" or "Flag2"

LoadPriorType – Determines the mechanism for loading priors.  Options are:

  * Unknown - Syngo Plaza will not automatically load priors. This value should be used if RIS is supplying the list of priors.

  * Related - When this option is set, Syngo drives prior loading.  Studies that are older than the current study will be loaded.

  * Exact - When this option is set, Syngo drives prior loading.  If both modality and organ match the current study and the date is prior to the current study, they are considered priors and will be loaded.

  * All - When this option is set, Syngo drives prior loading.  All studies that are available and have a study date-time older than the current study are loaded.  

Note that the Syngo Plaza viewer itself provides additional settings for configuring related priors.

LoadOnlyTop

  * False - (default) Images are loaded into the viewer

  * True – Patient will be open in the Patient Jacket feature of Syngo Plaza. Images will not be loaded into the Viewer 

The RIS zip file will now include the Jint.dll.