Some time ago, CMS mandated collection of Ethnicity indicators. Specifically, upon registering a patient, we were required to ask if he/she was Hispanic/Latino. The acceptable responses were:

Y = Yes
N = No
D = Declined
U = Unavailable

We built a Customer Defined Query and attached the screen to the ADM Census tab for all patient types. The query was setup as a Demo Recall field to ensure the data would persist beyond the ADM File Maintenance Parameter.

Pulling data on ADM Report for time frame within ADM File Maintenance Parameters:

Detail DPM: ADM.PAT.main

xx.ethnicity
DAT=FREE
LEN=10
VAL=@cd.response[@urn,"MY.QUERY"]

Pulling data for time frame which exceeds ADM File Maintenance Parameters:

Say your ADM File Maintenance Parameters are only set to 90 days and you want to pull patients within a specific admission date range exceeding our parameters. Write the report using:

Detail: ABS.PAT.main
Index: ABS.PAT.adm.x

You have to look to the MRI.DRC DPM to pull the data. The following Footnote is a dummy fragment call that essentially opens a connection to your MRI database (of course, replace the “FAC” with your Facility code):

AL START %Z.rw.fragment(“”,”MRI.FAC”)

If you are familiar with reading Meditech’s Data Definitions, you’ll notice that the cd.response is stored in the following segment:

customer.defined.queries <—– segment
[medical.record, cd.query] <—– subscripts

Meditech teaches us that “subscripts” are keys to accessing data. Meditech’s website also teaches us that the link between ABS and MRI.DRC is:

ABS.PAT.mri.urn = MRI.DRC.medical.record

That means in an ABS report, you can use @mri.urn as the subscript to pull an MRI.DRC field. To finish up this example, create a custom field as follows:

xx.ethnicity
DAT=FREE
LEN=20
VAL=@MRI.DRC.cd.response[@mri.urn,"MY.QUERY"]

I recently attended a leadership workshop, the best seminar I have ever been to in my professional career, where I was asked if my work is a job, a career, or a calling. What’s the difference?

Job: we perform primarily for pay and benefits. Punch the clock, do what is minimally required to keep our jobs and pay the bills.

Career: we have larger goals (advancement, recognition, etc.) Come to work early, leave late, and take work home.

Calling: a job that is intrinsically rewarding. Our work contributes to the “greater good.”

We all know which one of the above sounds the most fun, and which one sounds like the best employee to have working for you. But personally, I can see being effective with any of the options. But what makes you happy? What makes me happy? After reflecting for a few minutes, I realized that I’ve worked and succeeded in focusing on my career , but as of late, my labor was just a job. This realization was somewhat depressing to me, so I shared my concerns with my boss.

Luckily for me, my VP is…what’s the best way to describe him…he’s a damn cool guy. In addition to being a brilliant, knowledgeable , and effective leader, he genuinely cares. At this point in my life, I truly want to focus on my calling, and my boss tasked himself with determining how he and our organization could facilitate my goals.

Pretty cool.

I’m not sure if the greater moral to this story is to find your calling, or to find a job/boss who cares. In either case, I find myself happy with my work and goals. Furthermore, as manager, I am trying to emulate the leadership qualities and strategies of which I have been a lucky beneficiary.

I have a report built in BAR.BCH.transaction.items. The challenge was to figure out if the item.procedure was a charge explosion (Replacement Code) or if it was a regular charge. At the transaction.item level, the only way I could see the procedure was associated to a replacement code was in the @item.comment field.

For example, if procedure “456″ was a replacement code/charge explosion triggered from procedure “123″, the @item.comment field would have the following:

456|FROM 123

Hence, you could use string extraction like so:

@item.comment#”1 “

The above code would output: 123

As you know, Meditech stores Dates and Times in separate fields. If you wanted to write a report to select records between specific dates/times, it’s a little more complex than using the “BETWEEN” keyword like SQL. Here’s an example to select patients admitted between a specific date and time range:

Setup your report to Select on a date range as usual:

admit.date
GE
FROM DATE

admit.date
LE
THRU DATE

Add the following Select Fields as well:

xx.time.1
IG
FROM TIME

xx.time.2
IG
THRU TIME

xx.check
EQ
1

Now define the following fields:

xx.time.1
DAT=HHMM
LEN=4
VAL=c.xx.time.1

xx.time.2
DAT=HHMM
LEN=4
VAL=c.xx.time.2

xx.check
DAT=FREE
LEN=1
VAL=IF{@admit.date_._@admit.time’<(b.admit.date_._c.xx.time.1)’>(e.admit.date_
VAL=._c.xx.time.2) 1}

This method works because dates are stored internally in Meditech in the format YYYYMMDD, and times are stored in the format HHMM. Your xx.check field concatenates the two values and treats them as numeric values allowing a simple numeric comparison.

This example is written in ABS.PAT.main, and shows how to pull data from BAR.PAT.top (Meditech C/S).

Create a macro named “d” like so:

@SETUP.BAR.INDEX,
END

SETUP.BAR.INDEX
@account.number^BAR.PAT.number^ABS,
DO{@Next(BAR.PAT.account,BAR.PAT.number.x) .,
@BAR.PAT.account^BAR.PAT.account,
@DO.BAR.STUFF}

DO.BAR.STUFF
;blah
;blah

I set the BAR.PAT.number as the @account.number. A loop lets me use an index of choice — in this case BAR.PAT.number.x. Since that index’s first subscript is number, and I just set it in the previous step, NPR immediately finds that record, sets the BAR.PAT.account subscript, and then allows you to DO.BAR.STUFF.

Enter the following Footnotes:

AL START %Z.rw.fragment(“”,”BAR.KIC”)
AL D d

The bogus fragment call simply opens a connection to BAR.DB.