header title imageheader spacer image

Inside This Issue

    VCS Practice Expertise
    Siemens

  • Invision
  • Soarian
  • Project Management
  • MS4
  • OAS Gold
  • Technology and Integration

Innovations 2007

The Marriott
Philadelphia, PA
08/12/07 - 08/15/07

Siemens Practice Newsletter
Volume 2 Issue 1

TROUBLESHOOTING SOARIAN RULES ISSUES:
By Brandon Wiley

Rules errors can be found in three ways, with the first two accessed via Rule Builder, and the third by accessing the Rules Engine Server.

  1. Rules syntax checker
    • From the menu bar: Rule\Check Syntax
    • Hot Key CTRL-T
    • Icon in toolbar (blank page with blue checkmark)
  2. Run-time errors (debug)
    • From the menu bar: Debug\Go
    • Hot Key F5
    • Icon in toolbar (right-pointing solid blue triangle)
  3. MXSDEBUG.LOG file on the Rules Engine server.

The syntax checker will validate that proper syntax was used in the rule, but cannot guarantee that your rule will give you the desired results. Launching the tool will tell you if there are any syntax issues that are found, and can issue errors and warnings. Errors will keep the rule from executing at all, while warnings will not stop execution, but may affect the final result of your rule. The types of errors typically found by this tool are mis-spellings, improper logic, and punctuation errors (as Arden Syntax has strict requirements about proper definition of statements/slots within the source code of the rule).

Run time errors are found using the debug tool, and are higher-level errors, such as missing TDE entries, or communication errors between the Rules Engine and the source system. Since the Rule Builder does not require the initialization of variables, this is also a helpful way to check for misspellings/issues with variables within the rule, by validating the variable names within the Rule Data display when debugging the rule.

To use the debug tool, you will need to use an event data profile. If you do not have one, you will have to create one. The only two variables you need in a Soarian event data profile are:

  1. PATIENT_OID
  2. MXS#ENVIRONMENT

The patient OID is an internal Soarian patient identifier, and, per Siemens, can only be obtained by manually running the model rule SOARIAN_ALRET_RETURN_PATIENT_OID within the Soarian UI, once promoting it to Production status.

The MXS#ENVIRONMENT will be set to the same environment that you use to log into the Soarian Desktop Admin Tools applications.

If a rule passes both of the Rule Builder tools, but is still not returning the expected values or functioning as designed, verify your Targets and Qualifiers, particularly your Qualifiers, to ensure they have been entered correctly.

If that appears correct, access the Rules Server you are working with, and ensure that the MXS.INI file, typically located in c:\WINNT, has the value of DebugLevel=2, then go to the file MXSDEBUG.LOG, also typically located in c:\WINNT.

This file shows all the details of the query that was made to the Rules Engine, and the responses it receives. It helps to have experience with analyzing variable-length delimited records (such as HL7 interface transactions), as this is the layout of the messages that are received/returned from the Rules Engine.

For more helpful Soarian hints email us at vcs@getvitalized.com.