NPR Tip: Various “Gotchas” in MEDITECH field names

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:

• Account number
  
  • In ADM.PAT: acct.number
  • In ABS.PAT: account.number
  • In BAR.PAT: @number (don’t be fooled by “account”)

• DRG
  • In ABS.PAT: drg
  • In BAR.PAT: calc.drg

• Admission's URN
  
  • In ABS.PAT: @adm.urn
  • In ADM.PAT: urn (makes sense once you get used to MEDITECH practices)
  • In BAR.PAT: @int.number (what?!)
  • In MOST clinical modules (OE, PHA, LAB, NUR, RXM): @patient
  • In SCH.PAT, however, @patient = mri.urn
  • And just to mess with us further, the admission urn is in two places — @acct.number and @adm.int.urn

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:

• Use the DPM Pointer and Offset/Local/VAL columns of the data definition to figure out what misleading or misbehaving field really contains. So, when you fail to link to ADM.PAT.name using SCH.PAT.patient field, the fact that the DPM is “MRI.PAT” instead of ADM.PAT could be a vital clue about what is going on. Also, if you look at the value for a record, you can typically tell by length and leading alpha that is an mri.urn rather than an adm.urn.

• If you need to loop on a structure in the same DPM (for example, to check activity in NUR documentation report when you want to check data on mom in a newborn report), do your looping in a program so you don’t step on a subscript that the report is looping on. Or, save and restore the subscript you change by putting it into a local variable, then changing it, then putting the local variable back into the subscript.
  
  For example, you need to check visit history of a patient: @unit.number^unit.number,
  Urn^SAVEURN,
  “””^urn,
  DO{@Next(urn,@unit.index) @CHECK.VISITS},
  SAVEURN^urn

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 reportwriting@iatric.com to discuss how we can help support your team!