Written by Joe Cocuzzo, Senior VP of Report Writing Services - iatricSystems
What's in a name?
In teaching NPR, RD, and SQL from DR, a big chunk of my time is spent helping students figure out where data is kept (for example, which segment in NPR), and then what field names are called. MEDITECH segment structures and field names are built “by hand” by the application developer, which results in some unfortunate inconsistencies that make our Report Writing lives harder. This post examines MEDITECH field naming across applications, identifies some various “gotchas” to be aware of, and provides some tips for how to overcome those challenges.
1) Fields that return the same value, but have a different name in different applications/DPMs
It’s really too bad that the MEDITECH Report Writing group can’t go into data definitions and provide standardized naming for a set of common fields to make report writing easier. Such a change would have no adverse effect on application software or existing reports. You could just create a naming convention like, “rw.acct.number,” “rw.unit.number,” “rw.adm.urn,” “rw.mri.urn,” etc., and add a mapping in the data definition.
Examples of fields and their names across various segments:
2) Fields that have different names, but translate to the same local variable:
In NUR, @td.act.date and act.date translate to the same local. This means you can create an infinite loop or premature end if you are in a report in the documented activity segments, and then you need to loop on something in the activity segment.
3) Fields that have THE SAME NAME, but are really different values (i.e., you can have false matching):
In C/S, MEDITECH created a new DPM for employee data called HR.EMP, they moved PP.EMP data to that DPM, and changed the data structures and fields somewhat. They named the “urn” in the main segment (HR.EMP) “employee,” but (as maybe a hint to watch out?) it translates to the local hly instead of jy (which is what it translates to in PP.PAY or PP.EMP, now defunct).
Meanwhile, time cards and other data in PP store a field called “employee,” but it isn’t the same value. So if you aren’t careful, you can write a field like this in a time card export: @HR.EMP.name[@employee], and you will very likely match to a DIFFERENT employee!
You just have to remember to do it like this, instead: @HR.EMP.name[@HR.EMP.pp.urn.x[@.db,@PP.PAY.employee]]
Even an experienced report writer can be fooled by this misleading and unfortunate naming practice. Most of us understand that the field urn is going to hold a different value across all applications even though the name is the same, because we understand the idea of a number wheel producing an internal storage subscript. But, when you create a variant subscript name like “employee” and use it in two different DPMs off two different number wheels, you’re creating a trap that forces many report writers to learn about a quirk the hard way.
What to do?
There was a MUSE enhancement request many years ago, asking that a standard set of fields with the same name be created for common items like account number, unit number, patient name, adm urn and mri.urn. It was REJECTED.
There’s nothing to stop the MEDITECH RW group from adding a set of these fields to the standard data definitions for the MAGIC, C/S, and 6.0 platforms. Existing procedures and reports would not be affected, and once the new data definitions arrive, existing and new report writers could have an easier time finding what they need.
In the meantime, here are some tips:
If you need more help…
Our Report Writing team can help you fix reports, create new ones, make old ones faster, and much more. Simply reach out to your Iatric Systems Account Executive or our NPR report writing team at email@example.com to discuss how we can help support your team!