The AND_NOT and OR_NOT connectors

UPDATE:

Upon further testing and asking around, it looks like my initial reading of the AND_NOT logical connector was based on an older version of the documentation. It turns out that the AND_NOT logical connector is broken and is not recognized by the VGR parser. It seems that the OR_NOT operator works, but I still need to do some testing to confirm it. I've made some notations to this article where needed.

Original Post

When reading the VGR documentation and putting together my VGR Cheat Sheet, I found that, in addition to the familiar logical connectors {AND, OR, THEN}, there are also the AND_NOT and OR_NOT connectors. If you're not sure what I'm talking about when I say logical connectors, this is how the VGR Handbook defines them:

Connector: A logical connector for linking multiline VGR rules. This only applies to IF statements with multiple conditions, and IF statements where there are multiple commands in the THEN clause.

That's to say, that seventh piece of your VGR code that:

• Connects multiple IF statements: IF ... AND ... AND ... THEN
• Connects multiple lines after the IF: IF ... THEN ... AND ...

If you look at the Logical Connectors section of my VGR Cheat Sheet, you'll see four entries: AND, AND_NOT, OR, and OR_NOT. Just as you might expect, the AND returns true if both IF statements evaluate to true and the OR returns true if either IF statements evaluate to true.

So what about the AND_NOT and OR_NOT logical connectors? They are a little more specific. The AND_NOT returns true if the first IF evaluates to true and the second IF evaluates to false. Similarly, the OR_NOT evaluates to true if the first IF evaluates to true or the second IF evaluates to false

What is VGR?

Most folks, when I tell them that I know VGR have the same question: "What is VGR?" Well, the short answer is that "VGR is a scripting language designed to specify rules for implementing decision support"[2] from within McKesson's Horizon Export Orders system. But that's only half of the story.

Have you ever wondered where the acronym "VGR" came from? Well, here's a bit of a history lesson.

VGR was originally designed for WizOrder, Vanderbilt University Medical Center's (VUMC) computerized physician order entry (CPOE) system. In their words, it was designed to deliver "high-quality decision support to clinical end-users" and "to make it easy for non-programmer domain experts to enter rules."[2]

Fix Your "Exit Check Loop" with EXITCONFIRM

With Meaningful Use Stage 1 requiring the implementation of "one clinical decision support rule relevant to specialty or high clinical priority," many hospitals have utilized the HEO feature known as the "Exit Check" to check for certain actions or conditions (or the absence of certain actions or conditions) and prompt the user to address the issue. The Exit Check runs a user-defined rule when the user clicks the "Done" button in HEO and can include opening an iForm. While an iForm is often the best way to both have user answer a question AND give them information as to why the question is being asked in the first place, it has often been found that showing an iForm during the exit check "restarts" the process and kicks the user back to HEO instead of moving forward to the confirmation screen.

Placing Orders with a Multi-Select Prompt

In HEO, some prompts are known as "Multiple Choice" prompts. In other contexts, "Multiple Choice" might mean that you have to choose only one from a list of options. In HEO, that's known as a "List of Values" prompt; the "Multiple Choice" type prompt gives the user the option to choose multiple options from the list that is given.

Sending an @VGR Command by Itself from a VGR iForm

As you may or may not know, in VGR, you can trigger another VGR iForm by placing an "@VGR=myNextForm" command in your order string. This works great when it's being placed with one or more orders before it, but it seems to have trouble when placing it by itself. For example, if you have an iForm with a number of orders and a trigger for a follow-up iForm, it works great but only if the user chooses one or more order and the iForm. If they choose the iForm and none of the other orders, it throws an error.

The error is along the lines of "unable to open VGR file mynextform^^^.vgr" Up to this point, many sites have gotten around this issue since each of the iForms use a "tracking order" on it so there would always be at least one order. However, since the best practice is to use outlines to do the order tracking, we needed to find a fix for this problem that doesn't involve the newly unecessary tracking order.

Displaying Custom Lab Mapping in VGR iForms

If your facility is using HEO Mapped Lab Concepts, I'm fairly certain that you've found that the McKesson built-in lab concepts are a good start, but are only a starting point. Most facilities have many more lab concepts that they would like to display and use for clinical decision support (not to mention other creative uses of the Lab Concepts to bring HED non-lab values to HEO). To accomplish these things, you need to create your own custom-built HEO Mapped Lab Concepts.

If you've gotten to this point, you may have found that, while the newly created lab concepts are available to the rules writer (and therefore available to Standard iForms), when you try to use @@patient.lab_result.myLab.value@@ or @@patient.lab_result.myLab.date@@ in the HTML of your VGR iForms, it doesn't work.

The Benefits of Building an Outline for VGR iForms

We started building our VGR iForms before we got any real formalized training, but fortunately for us, we hadn't started using VGR until close to when we went for training. During the training, we got some very good advice:

"When building a VGR iForm, it's best practice to build an outline with all of your orderables first."

We didn't get a full explanation of the reason at the time, but I can tell you from just a few months experience and looking at the larger picture, it's the best advice that he could've given us. The quick explanation that he gave to us was that it helped separate the clinical duties / responsibilities from the technical / development duties and that's certainly true, but it's only a piece of the puzzle.

Diagnosis Keyword Search

Had a neat question come up the other day and it lead to an even neater script that I thought I might share with you. The question was; if a patient is diabetic, can we indicate that on the diet iForm for...(some medical reason, I kinda blank out on those)...? But the problem was really interesting and got me to thinking.

Reason for Exam Prompt

We had to add this to several of our forms recently, so I thought I'd show you our solution to it.

The Problem

We have to put a reason for exam text box on our radiology items. If we put one box that loads the same reason into each load string, it's simple, but doesn't offer our doctors much flexibility. However, putting a separate reason box on each item can be unwieldy and if they're all for the same reason, time consuming.

Lose the Tedium - Automate VGR Variable Initiation

Have you ever put together a long iForm with what feels like hundreds of checkboxes, radio buttons, dropdowns, text boxes, and buttons only to realize:

"Oh wait, now I have to map this monster."

I know I've been there, so I decided to do something about it.

Forget Something? - VGR Cheat Sheet

When we attended McKesson's VGR Training class, we got an electronic copy of a VGR "Cheat Sheet," basically a one page reference guide to the available VGR commands. Inspired by that, I decided that I'd make my own. Please note that this cheat sheet is not exhaustive; there are plenty of things that I left out in the interest of space (for instance, there are lots of other prompts listed in the official documentation, but I only listed the "most commonly used" ones, at least in my experience).

At any rate, I figured that this would be something that the community at large may find useful. Enjoy!

Trim Your VGR - Clear Default Text

The Problem

You know what always annoyed me?  Having to have multiple @LOAD_ORDER strings in my VGR just to check whether a textbox was left blank (and let's not even talk about when there is more than one textbox).

So, for example:

# ED CHEST AP PORTABLE
EDIT,IF,,chkChestAPportable,EQ,"true",AND
EDIT,IF,,txtChestAPportableComments,NE,,THEN
EDIT,SET,,orderstring,CAT,"@LOAD_ORDER=OIS=123456^^^OOS=0^^^7810=`cboChestAPportableReason^^^53=`txtChestAPportableComments"

EDIT,IF,,chkChestAPportable,EQ,"true",AND
EDIT,IF,,txtChestAPportableComments,EQ,,THEN
EDIT,SET,,orderstring,CAT,"@LOAD_ORDER=OIS=123456^^^OOS=0^^^7810=`cboChestAPportableReason^^^53=..."

I knew that there had to be a better way, and through some trial and error, I came up with a solution that's worked really well for us. But before we get to that, let's take a quick walk through the process and see why some of the early solutions didn't quite work right.