Joe Cocuzzo, Senior Vice President – Report Writing Services
MAGIC and Client/Server Time Stamps and how to use them.
Report with “elapsed time” information
Export of Doctor Dictionary Entries created or edited on/after selected date.
List of NPR Reports “run since” elected date
FIRST – The Geeky Background Information…
Most dates in an NPR application are stored internally in YYYYMMDD format and most times are stored in HHMM format. This is convenient for sorting. When a YYYYMM date is printed or displayed, the system country value is checked to determine whether you get MM/DD (US) or DD/MM (everywhere else) format.
Sometimes, MEDITECH uses a different value for a combined date and time, using the number of seconds since March 1, 1980 or, for a date in PCI or RAD, the number of days since March 1, 1980. Typically uses of this value are:
Building a unique subscript for a transaction queue. Here is the Admissions Transfer Queue from a MAGIC test system (the system appends a tie-breaker when two transactions file in the same second).
Storing a date and time in a user or report activity log. Here is the MIS activity log from the same MAGIC test system:
Here is report activity for a custom NPR report (a face sheet):
Creating a “last update” stamp in a dictionary.
Creating/converting “number of seconds” values.
To produce the “number of seconds” value, use the @.sd NPR macro.
To convert the “seconds” to a YYYYMMDD date use %Z.date.in.magic(@.sd)
To convert the “seconds” to a HHMM time use %Z.time.out(@.sd)
To convert an NPR date and a HHMM time to a seconds value do this:
First Report Example – show elapsed time for report in trailer field.
It is sometimes necessary or useful to know how long it takes a scheduled or spooled report to compile and complete. One example is when you are designing a large data export and want to run a portion of the range to project how much time the full export might take.
You can do this in two easy steps:
Store the starting time in seconds, you can do this right in an “AL START” footnote as follows:
Compute the elapsed time in seconds in a field in the report trailer, convert to minutes.
Running the report through a year of transactions, elapsed time 20 minutes:
The Client/Server approach is identical, here is some sample output for one month of transactions:
Second Report Example, all records edited on/after selected date:
Sometimes it is useful to have a report you can run for all records, or only records updated on or after a selected date. For example, rather than sending the entire doctor dictionary to some other-vendor system, you could send an initial export of all doctors and a weekly “update file” of new or edited entries.
Just create a simple dictionary report and add a computed selection field. If you add the BEGINNING keyword, you can run from “BEGINNING” to do a full export of all records.
The xx.last.updated field converts the last update time stamp from “seconds” format to YYYYMMDD
Note that the “last.update” field will not be visible in the field lookups, but all dictionaries have this field, and if you enter it in your computed field logic, it will work.
Here is sample output from a Client Server System (again, C/S and MAGIC approach is identical):
Third Report Example: List of all NPR Reports run on/after a selected date.
A MEDITECH MAGIC hospital doing a migration to another platform asked me for a list of NPR reports run in the past year. MEDITECH keeps a log of the last 10 runs of a report in a child segment, with a subscript @run.time which is a “seconds” value. To select only reports with the most recent run, we need to somehow get the “last” (largest) value of @run.time and convert to an NPR date (YYYYMMDD) to check to see if it is on or after T-365 (or some user supplied date).
Step one is identical to the dictionary export example above, create a report in the “main” segment, and add a computed select field:
The code for the xx.date field is slightly more complicated because we want to get the largest value of run.date and convert to YYYYMMDD format.
We can either use the @Prev operator or the @Last operator to get the largest value of @run.time for each report. The @Prev operator does a “logical previous” or a “minus” on the subscript, which “backs up” one entry in the list and assigns the previous value back to the subscript. The @Last operator does a “logical previous” but does not assign the value back to the subscript.
Looking at the object code may help you understand the difference:
So our xx.date field should look like this:
Because we have an IF statement around the code, the value of the field is the condition of the IF. If there was no activity for a report, the @Prev(run.time) would return nil and the IF would return nil, so the report would not be listed.
The code for xx.date using @Last is shorter and because we can write everything in one expression, no IF if needed.
@Last approach has the advantage that you are not affecting the value of run.time, so if you used multiple fields on your report to show all activity, the code in the xx.date field would not cause problems. @Prev has the advantage of leaving run.time equal to the most recent run so you could put xx.date field on the picture (establishing run.time) and then use the field @run.user and it would be populated with the most recent run user.
Here is example output from a MAGIC site:
If we use the @Last approach and add some multiple fields, we can add activity listing to our report:
The xx.act.date field converts run.time with %Z.date.in.magic. We would not want to use the xx.date in the set of multiple fields because that would give us the most recent run date, not each run date.
For Client Server, you need to add FNC=LST for the field to work.
Here is sample output:
Three example reports (both C/S and MAGIC formats) have been placed in our report library:
Show Elapsed Time for report run: BAR.PAT.zcus.is.eupdate.et
Doctors created/edited on/after selected date:
NPR reports last run run on/after selected date: NPR.REP.zcus.is.eupdate.last.run.since
Visit our report library at 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:
For more information, please contact Karen Roemer at 978.805.3142 or email
This article originally appeared in the March 2015 issue of Iatric Systems Updates! newsletter.