When is an Order Actually Two Orders? (Client/Server or MAGIC)

Moving report detail segment to count the same record multiple times.

I recently had a site ask for a report listing all telephone or verbal orders, with an option to show just unsigned or both signed and unsigned orders. The hospital wanted the option to sort by patient or by ordering provider.

This is a simple report (or so I thought), just select orders for an order date range and check to see that the source is “V” or “T”.

The site reported that I was “missing” some “verbal orders” and gave me an example, which actually looked like this:

The site thinks of this as two orders, an original written order from DAND, followed by a subsequent order (a stop order actually) by telephone by PCOWAN.

I can adjust the selection logic so that I pick up orders with a source of T or V, or an edit.pom.source of T or V, but I might need to list the same order on different dates and under different doctors. I can’t use the unsigned index because the report needs to be able to include both signed and unsigned orders.

Here is an example order that needs signing by two different doctors:

How can I get my report to print the same order under each doctor who either entered the order with a source of V or T, or edited the order with an edit.pom.source of V or T?

I have three options:

1. Build an MV array for all my output, or some temporary structure that I loop through with an ECB-ECE loop.The disadvantage of this approach is that all my fields would need to be computed fields and automatic totaling with Z.count or FNC=TOT would not be available.
2. Rewrite the temporary file to include the same order multiple times. This works well, but as the syntax checker blocks 1 ^/R.TF you need to code around the syntax checker, especially in MAGIC where1^ /[“temp”,SORT1,SORT2…] only works if the sort file stays under the MIS max records parameter and does not swap out to disk.
3. Move the detail segment of the report from the main (where you get each order one time only) to the edit.data segment, and select the order if either of the following are true:- The edit.urn = 1 and the source is V or T

   - The edit urn >1 and the pom.edit.source is V or T

   In each case, test whether the user has asked for unsigned orders only and if they have, check to see if the order was subsequently signed by the appropriate doctor.

Option C seems best for this example. Let’s see how the report should be written:

We set up the sorts as follows:

xx.sort1 sorts by doctor for the first edit transaction for provider sorting, by the @edit.pom.provider on all other transactions for provider sorting, and by patient name if name sorting is selected.

xx.sort2 sorts by patient name if you are doing primary sort by doctor, otherwise lets the orders list by edit.date by setting the sort at this level to a 1.

Remaining sorts are by edit.date, then urn, then edit.urn.

The selection is for an order date range, and then we have a computed selection field:

The xx.ck field calls a macro as a program, and passes the urn and the edit urn as arguments A and B:

We check each edit transaction. If we are on the first edit transaction that is the initial entry of the order, and we want to include the order if the @source is V or T. For additional flexibility, the user can elect to discard signed orders so we have some extra code to throw out signed orders by looping forward through subsequent transactions to see if the doctor did sign. Logic is similar for edits to orders, but for those we are checking for @edit.pom.source of V or T and checking the @edit.pom.provider to see if that doctor signed.

When we look for signing, we parse out the doctor from the “signed for” transaction with the % (right of) operator to get everything to the right of position 16 and for good luck we strip any leading and trailing spaces with :0S.

The final piece is to write a “detail” macro to loop forward to find the signed date and time and to calculate some elapsed time values and characterize the order as either not signed, on-time, or late.

The detail macro is attached with a footnote. For Client/Server only, you need to add a BUF NONE footnote. MAGIC would just have AL D detail:

In the C/S version of the report, you need to prevent "buffering" of the detail segment into a temporary structure. Otherwise, the detail macro looping code will loop on a temp structure that will only contain the one edit transaction that was selected by the report. Your code in the macro will be perfect, but will be changed when incorporated into the report itself (the .R program) and will not work at all to find signing transactions.

Here are the gory details (relevant to C/S only):

Macro source code: (written fine, should work)

Macro object code:

Report object code:

Then your macro also tries to loop on this temp:

If we add BUF NONE footnote:

Here is a sample of the report, with PHI removed. We show whether orders were signed within 72 hours and some percentages per doctor and for all doctors:

Client/Server and MAGIC version of this report OE.ORD.zcus.is.phone.and.verbal.orders2 are available on our website in our report library on our website: http://www.iatric.com/Information/NPRReportLibrarySearch.aspx.

You can find additional Report Writing Tips on our website at http://www.iatric.com/Information/NPRTips.aspx, as well as information about our on-site Report Writer Training and Report Writing Services.

To subscribe for email notifications for new Report Writing classes, please follow this link:

http://www.iatric.com/Information/Classes.aspx.

For more information, please contact our NPR report writing team at reportwriting@iatric.com.

(This article originally appeared in the September 2013 issue of Iatric Systems Updates! newsletter.)