Written by Joe Cocuzzo, Senior VP of Report Writing Services - iatricSystems
Recently, MEDITECH became aware of a way code could be written that could result in changes to the database, and they have released a change to the checker that has the unfortunate side effect of disabling many innocent reports. We have had customers with tens to hundreds of reports affected. Most hospitals are getting this change along with a 5.66 update, but I believe it can be delivered in 5.64 as well.
It is very important to fix all affected reports that are still in use and move the fixed reports into your LIVE directory before MEDITECH runs the syntax checking job in LIVE, or you will have reports and screens crashing due to broken reports.
In MAGIC, you will get two new routines on the NPR customization menu:
In C/S and 6x, you will get two new routines on the Reports menu:
Typically MEDITECH runs the first "Check Macro Syntax" background job and you may be a lucky winner and see many reports affected.
Here is a C/S site with 132 reports broken by the change:
Here is a MAGIC site with 784 reports broken:
Unfortunately, the "Print Syntax Results" routine does not include report activity, or allow you to limit the listing on some kind of usage basis, so you do not have an easy way to triage your fixing, to avoid wasting efforts on:
ADM.PAT.zcus.is.great.great.great.grandfather
ADM.PAT.zcus.is.great.great.grandfather
ADM.PAT.zcus.is.great.grandfather
ADM.PAT.zcus.is.grandfather
ADM.PAT.zcus.is.father
And you can just fix: ADM.PAT.zcus.is.son (provided sonny’s macros are local).
This month I will show how you can write (or how I have written) a report that allows you to restrict your list to reports with activity on or after some reasonable cut off date, and be reasonably sure that you have fixed all reports in use. Note that if you call report macros as programs from a CDS, that report will not have activity. You can check the CDS issue by trying to re-file the screens that might be affected in TEST after the syntax check has been run.
The reports I will describe can be used "as is" and should prove very useful for sites with many reports caught by the new syntax checking. You do not need to go through my detailed discussion of how the report is written, unless you are interested in the techniques I used, and furthering your geeky education.
The first step to duplicate the standard report is to look at the MEDITECH "Print Check Syntax Results" report that they deliver with this change.
We can list the customization menu from LIST REPORTS to see the name of the procedure: NPR.PROC.check.syntax.print.
Just for fun, we can try to initialize from this standard report:
At Iatric Systems, our slogan about the "Initialize Report from Standard" routine is: "The More You Need It… The Less Likely It is to Work."
In this case, it is not complex code and a difference between the two Report Writing tools that stops us, but the fact that MEDITECH set up the data segment they created to not allow access for the Customer Report Writer.
We can list the report and see that is uses a detail segment of NPR.PROC.check.syntax, and if we look at the data definitions with Programmer’s NPR we see:
While we are poking around on the MEDITECH side of the house, we might as well take the opportunity to copy (to the Windows Clipboard) the ID code from the compile # field (cs.urn) so we can use the same lookup in the Customer Report Writer report we are about to create:
This is an extra credit step, and we could have just prompted the user for an integer with no lookup and our custom version of their report would still have worked fine.
Ironically, the C/S lookup attribute is ID=%NPR.PROC.check.syntax.id(A), but the C/S syntax checker won’t let you call an NPR.PROC program. So your syntax checker report gets stuck on the syntax checker. The solution is to copy the source code into your own NPR.REP.zcus.is.rw.check.syntax.with.activity.M.id macro, add the NPR.PROC dpm to all the fields, and grumble to yourself about the whole unhelpful syntax checking situation.
How can we deal with the fact that the detail segment "check.syntax" cannot be used by the customer report writer? Since we can write a report in NPR.REP and get report data (urn of report, title, and activity), we can write a loop in a start macro to go thru the "check.syntax" segment, check activity in NPR.REP, and make a list of reports in slash that our NPR.REP based report can use for selection.
Both C/S and MAGIC reports can get data from segments set to "Cust R/W Access" = N, so we can write a start macro in NPR.REP and loop on all the reports found by the compile selected and then check last activity.
The MAGIC DPM lookup will even show you the segment and fields, and the segment information:
Unfortunately, the C/S field lookup program will not show segments flagged as unavailable, but you can still use them in a macro or computed field or line attribute.
Our MAGIC report in written in NPR.REP, with a detail segment of npr.rep.main.
Our C/S report is written in NPR.REP, with a detail segment of main.
In the selections we prompt for the compile number, select urn against a list in /URN, provide an option to include or omit activity, and allow the user to provide a "last run on/after" date.
The start macro of both reports (MAGIC or C/S) contains identical code:
Both reports use two ECB-ECE loops to print both the macros found by the syntax checker:
This loop goes thru the syntax checker data and prints the macro and the syntax message:
This loop prints activity:
Here is sample output from the C/S version of the report.
Remember, these reports are designed to be used "as is," so even if you skimmed through this entire article to get the report names from the bottom note, you can take these and use them to cope with the recent syntax checker changes and possibly save significant time and trouble.
We have uploaded the MAGIC and C/S version of these reports to our report library under NPR.REP.zcus.is.rw.check.syntax.with.activity.
