Avoiding Fragments (Client/Server Only)

The "official" technique for crossing applications in an NPR report is to write another report as a fragment and call it via a utility program %Z.rw.fragment. The fragment then takes over and prints or puts some data in /R.FRAG.VAL that you use back in some computed fields or an "MV" array back in the main report to print the data from the other application.

Fragments allow you to cross applications without needing to write any loops, but they carry a sizable performance penalty. Running our example report for one month at a LIVE site took 3.7 minutes to export 855 patients. A fragment version took more than twice as long to export the same set of records. (Also, it is more difficult to maintain a main report and one or more fragment reports, especially as the fragment calls tend to be hidden in line checks, ECB attributes or computed fields.)

In MAGIC, because there are only 10 prefixes, crossing applications without fragments is more complicated, requiring the programmer to "stack" or save prefixes open to one application, open them to another, retrieve data, then "unstack" or re-open the prefixes to the original application. A mistake will cause your report to crash or end prematurely. A mistake in a report called by a standard routine (a custom OE order format, a MAR, an eMAR or a PHA profile fragment) may cause applications to misbehave.

In Client/Server (C/S), MEDITECH creates unique prefixes per application, so it is possible (and relatively easy) to open all applications needed at the start of a report and have all data, indexes and programs available in the same report.

This month, we will show how to write a Client/Server Abstracting report that goes from Abstracting to MRI to get patient address information. This is a typical "fundraising" type report, which often needs to include patients who have been purged from ADM. ABS data does not purge and is nicely indexed by discharge date and patient type. (You could write the report in B/AR, but that would spoil our nice example.)

Step one is to select a detail segment and index:

We want inpatients for a discharge date range and the "dis.date.x" will allow us to do an index based selection by @pt.status and @dis.date.

We want to de-duplicate our list, and send just one record per patient, so we suppress the detail region of the report:

In Report Writer classes, I call this a "Nancy Reagan" report as in "Just Say No to Detail."

To print one record per patient (versus one per account) we add a KEY region for mri.urn, after we sort the records by name.

You could either use a Header Key or a Trailer Key for mri.urn, the report functions identically with either option.

Then we set up selections:

We want the "IN" patients for a dis.date range, and only patients 18 years or older. This is typical for a survey or fundraising.

We also do not want to send to expired patients, and we don't want to just screen out @discharge.disposition NE "E" as you might have a patient with prior visits in your pool of records, so we will use a computed field to check the patient's final discharge disposition in MRI:

In the picture, we make a computed field for each column header, with the "VAL" equal to the text we would like to see for each column. If we typed the column headers into the picture, the text would not include a delimiter. If we use computed fields, our FD footnote will provide the desired delimiter automatically.

(Side note, in October 2008 one of our tips describes a utility Z macro that could be used for both C/S and MAGIC reports to automatically produce header fields. You can check it out at: http://www.iatric.com/Information/NPRTips.aspx?ID=138&FileName=updates-Oct2008.pdf That utility uses the field name or whatever you put in a HEADER= attribute as the column header and you just call it in the HR from an ECB or LC or footnote.)

Next we add fields from MRI.PAT and MRI.DRC to our field list, and place them in the HK2 region:

Then we need to create our computed field that excludes expired patients. We check to see if the discharge disposition stored in MRI.PAT has been flagged as Expired in the MIS dictionary. Most hospitals use "E" and just have one code, but it is just a bit safer and more universal to check the flag.

(Side note, MAGIC MRI has a field @exp date that can be used to indicate the patient died outside of the hospital. This field was created way back in release 4.6 or so. Since C/S MRI was based on 4.5, it lacked (and still lacks) this field. This means that C/S sites do not have an easy mechanism to flag patients as expired outside of the hospital.)

Do not be confused by the fields @expire.date and @expire.time in MRI.PAT (both platforms), these are dates used for MRI purges.

You might wonder how the report has the value of the mri.urn so that the field @MRI.PAT.discharge.disposition can be found:

Recall that we included a sort in our report of @mri.urn. The translator creates a set of loops through the temp sort index (or the permanent index if you do not alter the sorts) using the local variables from the data definition. This means that in the HK2 region, the value of "ea" is available for each patient.

If you watch the translation messages, you can see what the local variables are going to be for your report:

The macro needs to be "attached" to the report with a footnote, along with the footnotes we need to make the report a tab delimited download.

And if we run the report, we get a nice tab delimited download file. The little squares are the tabs. Tab delimiters have the advantage that they won't ever be found in data, unlike commas, pipes, or semi-colons. Plus they save one mouse click in the Excel text import Wizard.

This example report has been posted to our C/S report library: ABS.PAT.zcus.is.nofrag.http://www.iatric.com/information/NPRReportLibrarySearch.aspx.

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

Upcoming NPR Training Opportunities:

We are pleased to offer NPR Report Writer training sessions at host sites. Details and a course description are available on our website athttp://www.iatric.com/Information/Classes.aspx.

To subscribe for email notifications for new classes, please follow this link: http://www.iatric.com/Information/Classes.aspx

For more information or to reserve a seat, please contact our NPR report writing team at reportwriting@iatric.com.

(This article originally appeared in the March 2011 issue of Iatric Systems’ Updates! newsletter.)