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.