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

Show / Hide Elements based on a Checkbox

One of the best ways to save space on a busy iForm and make it easier to read is to only show certain pieces of information when they are relevant. For instance, if you have an order with prompts that need to be filled in, you can hide the supporting prompts until the order is selected and in most iForms, that means checking a checkbox.

So today, we'll look at how to hide and show an element on your iForm based on when a checkbox is checked / unchecked. Up until this point on the blog, I've mainly focused on how to get things done using the jQuery JavaScript framework, but today I've decided to be more inclusive and include the instructions on how to do this using "native JavaScript" as well. For each method, I've included two examples: one example of showing / hiding an inline prompt and one example of showing / hiding whole orders.

Clinical Decision Support - Using Lab Dates in JavaScript

This blog post was inspired by a question raised by Scantron (Michael) on the HEO iForms Google Group. He writes:

Hello all,

I was wondering if anyone is working with dates in java script? I have some criteria to order a CBC if one has not been completed in the past 24 hours. I can get it to subtract the dates and order the tests when I hard code the dates, but when using the @@patient.lab_result.Plt.date@@, the value brings in a carriage return symbol, and I get an unterminated string constant error. anyone have a solution for this?

My js:

var dt1 = new Date(Date.parse("@@patient.lab_result.Plt.date@@"));
var one_day=1000*60*60*24;
var time_diff1 = (parseInt(dt1.getTime()-dt2.getTime())/(one_day));

if (time_diff1 > 1 || isNaN(time_diff1)){
 $('#PtInr').val(1);
}

What comes in:

var dt1 = new Date(Date.parse("03/13/2013 09:46 AM
"));

InSight Conference 2013

I just got confirmation that I will be co-presenting at this year's InSight user group conference again this year with Dr. Mark Pratt and Bonnie McGuire. I co-presented on two sessions with them last year; it was a great time and a great opportunity to share ideas and meet other people that work with McKesson products. This year, the two educational sessions that we're presenting in are on Friday morning, so make sure that you get an afternoon or evening flight home.

If you have not had the opportunity to check out this conference yet, I highly recommend it. It's a great opportunity to see what's coming up, to hear how some other hospitals have faced (and overcome) the same issues that you may be experiencing, to meet other folks and share ideas, and to even hear directly from McKesson about what they think about all of these things.

If you are going to be able to attend this year, I'd love to meet you. I have such a good time geeking out about this stuff and talking about new and interesting ways to use the system.

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.

How jQuery Can Help Your iForms

You may have noticed that all of my code snippets up to this point have required something called "jQuery" and I've been remiss in not giving a more basic background of what this thing really is, what it can do for you and your iForms, and (maybe even more importantly) what it can't do for you.

jQuery is what is called a "javascript framework." That is to say, it's a library that helps make some javascript functions easier. If you at a facility that is not using javascript in your iForms and don't have plans (or the ability) to do so, then this has no bearing on your processes and, unfortunately, most of the "code" things that you'll see on this site will be out of your scope. However, if your facility is using javascript, but would like to expand your functionality, I'd recommend using a javascript framework / library such as jQuery (and there are others) to enhance your capabilities.

Using Special Characters in Your Dropdown Boxes

Have you ever wanted to pull out your hair when trying to map a dropdown box with non-alphanumeric characters in it?  It happens all the time: someone builds an order with a prompt that has a greater-than (>) or less-than (<) sign, a comma (,), a plus (+), an equal sign (=), an "at sign" (@), a colon (:), or other "sacred" characters.

Let's look at some examples:

Colon Use:


Plus Sign Use:



Avoiding the Issue in the First Place

I've heard that some sites go through the process of updating their prompts and allowed / recommended value lists in the toolkit to change "OTHER: SEE COMMENTS" to "OTHER - SEE COMMENTS" or "65+" to "65 or older" and that is a viable option, but can be time consuming.

(NOTE: if your facility is still in the early stages of setting up HEO, do yourselves a favor and avoid these characters as a rule. The best practice is to avoid these issues in the first place)

What the Issue is and Why This Happens

When the iForm gets submitted, the values in your form elements go through a process known as URI Encoding. Your alphanumeric characters won't be affected, but "special" characters will often be encoded using this process.

When data that has been entered into HTML forms is submitted, the form field names and values are encoded and sent to the server in an HTTP request message using method GET or POST, or, historically, via email. The encoding used by default is based on a very early version of the general URI percent-encoding rules, with a number of modifications such as newline normalization and replacing spaces with "+" instead of "%20". The Internet media type of data encoded this way is application/x-www-form-urlencoded, and it is currently defined (still in a very outdated manner) in the HTML and XForms specifications. (Wikipedia)

How to Work Around the Issue

Since VGR can deal with these special characters within itself, we just need to pass a value from the HTML to the VGR that does not get impacted by the URI encoding.  Then, in our VGR, we check for those specific value(s) and set it "back" to what it was originally.  Going back to our examples above:

Colon Use:

HTML


VGR

EDIT,IF,,cboExample1,EQ,"OTHER",THEN
EDIT,SET,,cboExample1,TO,"OTHER: SEE COMMENTS"

EDIT,IF,,chkExample1,EQ,"true",THEN
EDIT,SET,,orderstring,CAT,"@LOAD_ORDER=OIS=11111^^^OOS=0^^^111=`cboExample1"

Plus Sign Use:

HTML


VGR

EDIT,IF,,cboExample2,EQ,"65 plus",THEN
EDIT,SET,,cboExample2,TO,"65+"

EDIT,IF,,chkExample2,EQ,"true",THEN
EDIT,SET,,orderstring,CAT,"@LOAD_ORDER=OIS=22222^^^OOS=0^^^222=`cboExample2"

This code here just changes the value in the dropdown box variable to be just as if it had originally contained the characters, but since we're adding back the special characters from within the VGR it does not go through the URI encoding process and can be used just like any other variable.

Further Reading

Scott Morris is available for training, mentoring, troubleshooting, and iForms consulting. Find out more at www.thinkiforms.com

Milestones and Accomplishments

It's pretty amazing to be able to say this, but we just recently hit 10,000 views on this blog.  I know in the grand scheme of things, that's a drop in the bucket to what many sites get; some have gotten 10,000 hits in the span of time that it's taken for you to read this far into the post.  However, I still feel that it's an accomplishment worth noting.

Visit thinkiforms.com for
more information

Another accomplishment worth noting is that I've made the leap. You know, THE leap from working for a hospital to working as a consultant, and finally, now, for myself.  I've started a new company, "Think iForms, LLC" and am currently personally available to consult for short-term, long-term, or even in a mentoring role.  Do you want to get "Feature X" working?  Give me a call.  My contact information can be found on my website.

And you heard it here first, I am licensing my software that can Automatically Convert an HEO Outline to a VGR iForm.  This is a game changer that can catapult your sites in the speed and sheer number of iForms that you will be able to produce.  I'm piloting the software now; if you would like to be included in the pilot program or would like to see a working demo, contact me at scott@thinkiforms.com.  This is a limited time (and limited number of sites) pilot, so act now.

Happy 2013 - jQuery iForm Library, Anyone?

Happy New Year, everyone! The year 2012 was quite a year, wasn't it? And with 2013 just now beginning, I see a world of possibilities ahead of us. There are some exciting and scary things coming ahead in the world of CPOE; if your facility has attested for Meaningful Use phase 1, you have an idea of what I'm talking about.

I have some projects that I would love to unveil at some point this year. One of which I'd like to get some community feedback first. I've created a jQuery plug-in specifically geared toward iForms.