Written by Joe Cocuzzo, Senior VP of Report Writing Services - iatricSystems
Or in MAGIC only, you can add a GRP=<group mnemonic> attribute to a computed field in the field attributes.
Client/Server (C/S) supports the CH option but not the GRP= field attribute. This month we will describe the two options for MAGIC, and show how to duplicate the GRP feature with a custom ID program in C/S.
CH works well when you want to give the user a hardcoded set of choices. I like to use it if I am building a report with multiple output modes:
Here is how it looks when done (identical approach) in a C/S or 6.x site:
At times, however, you want to prompt the user for a selection from a Group Response dictionary in MIS. One example is if you are trying to allow the user to pick a particular group response element that you are going to compare to a query response to select records. Another example is where you want to create a special dictionary with a large number of entries that would not fit in a CH attribute string, which is limited to 255 characters.
In MAGIC, you can just create a computed select field, free text, length 10, and add a GRP= attribute.
Now the computed selection field presents the group response dictionary:
For C/S, the GRP= attribute is not supported, but you can get equivalent functionality by creating your own ID program (or using ours from the example report from this tip).
Remember, you can just USE this code as is (just change the group mnemonic at the top line to match the group you want to have for a lookup). The details below are for those interested in how the code actually works.
You write a macro as a program, and attach it view the "Edit Elements" option like this:
There are two steps in the ID program; first we loop through the desired group dictionary and create a typical MEDITECH dictionary file in a temporary structure.
Step #1
We want to turn this: |
Into This: |
The MEDITECH generic ID program we want to use for the lookup wants a structure that looks like this:
/GLOBAL[subscript]|0 = Y (active flag) |1 = name |2 extra fields as needed
So it is easier to just loop through the group response dictionary and create a temporary structure than to write a non dictionary lookup program (or find one). Also, a group response dictionary is never going to be that big, so moving it to a temp file works fine.
Step #2
Next we set up some arguments and call the standard C/S dictionary lookup program. The program has the following arguments:
Z.id(A,B,C,D,E,F) where
A= "name of" the structure to do the lookup on. We build our temp dictionary in the example in /LI so, we pass ^LI in the "A" argument
B = the value the user entered before hitting F12 (that is passed into our ID program in variable A)
C = A queued string of column headers for the dictionary lookup
D = A queued string of expressions that will build the data for each column
E = "AR" for restrict to "A"ctive entries and "R"eject new entries. This is what you want, because you don’t want to have the user able to create new entries and file them.
F = A title for the lookup window
Here is the section of the macro that does this for our example report:
And here is how the lookup behaves:
We have uploaded the C/S version of ABS.PAT.zcus.is.eupdate.choices.and.grp to our report library.