MEDITECH Surveillance Rules Engine

In MEDITECH 6.1, the Surveillance dictionaries are housed under Quality Management. Both Quality and Clinical staff will use these tools to monitor the patient population.



The Surveillance Rules engine functions differently than the Rules Engine used to apply clinical decision support in ordering and documentation. These rules are comprised of “Facts”. Each fact is built out separately and then added to the rule it’s going to be applied to.

The design philosophy behind this was to avoid “reinventing the wheel”. For instance, a “Fact” could say, only look at the INPATIENT population or only assess if a problem wasn’t present on admission. Once facts are built they can be applied to many different rules that assess for different things.



The above fact will assess the patient for a change in the level of consciousness. This fact will most likely be used is assessing the patient population for a variety of conditions: UTI, Dementia, Stroke, VAP and Sepsis for example all use these criteria.



Depending on the Item, (field, query, lab value etc) operator and modifier you are assessing you will be presented with different options to further define your “fact”. If your modifier is just “Equals” than you will not have to define old and new values.

In the example above, we are looking for a delta change. If the patient was one of the old values: Alert, Awake, Follows Commands and that changes to Drowsy, Lethargic, or Disoriented then we want to trigger a flag. This fact could be used on its own OR in combination with other facts. Perhaps we only want to trigger a flag if the patients level of consciousness changes AND they have increasingly low urine output.

Fun Fact: Greek Letters are not just for frats! They can be found in mathematics, finance, science and engineering. The Delta symbol represents a finite change (math), a sensitivity to price (finance), heat (chemistry) and the degree of freedom in two pooled populations (statistics). It’s all Greek to me though!

Once we have built our facts we can attach them to a Rule. In the next example we can see how multiple facts can be combined to make a rule.



On the main tab you can define what your rule will assess. Use the description tab to clarify the goal you want to achieve and list any queries that might be mapped in the rule.



The Rule tab is where you pull in all your facts, use the operator between facts to give your rule direction. In the example above we want to assess only the inpatient population for a change in consciousness. The operator AND combines the two, whereas OR would look for either fact to trigger the rule. Placing facts into groups helps organize your rule logic by adding a unique order to the assessment.

Once your Rule has been created make sure to rebuild the surveillance rules. This only needs to be done once initially and then subsequently with additional edits. In the Rules Engine Build Dictionary, build your rule by building (or rebuilding) the Surveillance Category.



Once the build is complete, it can be tested on a patient to verify it works correctly. Add the criteria to a test patient and then use the rule verification tool to make sure that patient is properly flagged. In the next example, make sure your test patient has a lactic acid level greater than 2. This helps you verify that you’ve got your facts straight (pun intended).



After building the rules, they can now be associated to a Surveillance Profile. These profiles can have 2 types of rules associated to them. Qualifying (The patient has met the criteria and has been added to the watchboard) or Removal (The patient no longer is at risk)