March 2, 2015, 9:05 am

The Key to Reducing Readmissions? Coordinated Care Transitions and the MEDITECH EHR

Under the Affordable Care Act (ACA), hospitals with high readmission rates now face penalties totaling up to three percent.

With its fully-integrated EHR, Medical Information Technology, Inc. (MEDITECH) supports the coordinated care transitions that help healthcare organizations eliminate unnecessary readmissions and maintain their bottom lines. Several key system features give providers the tools they need to see a complete clinical picture of their patients, inside the hospital as well as outside of it.

Read more.

February 25, 2015, 11:47 am

Battling Insider Threat to Patient Privacy

Organizations have suffered insider breaches

February 25, 2015, 10:18 am

Read how Benefis Health System eliminates mislabeled specimens

Discover how you can simplify specimen collection while preventing errors. Benefis Health System, a 6.0 site with 516 beds across two campuses, eliminated mislabeled specimens at their organization. Read their story now to learn how.

“Trying to enforce positive patient identification used to be a constant battle, but no longer,” reported Kelsy Diekhans, MT(ASCP), Clinical Laboratory Scientist and Laboratory Systems Coordinator at Benefis Health System. She added, “Since we went live with MobiLab, we haven’t had a single mislabeled specimen.”

Read their story now.

February 24, 2015, 9:56 am

MUSE Webinar: Driving Restrictive Transfusion Practices Using Computerized Physician Order Entry

March 3, 2015 at 1 PM Eastern
Cost: $100

Based on the latest recommendations from AABB regarding liberal usage of blood transfusions having NO positive impact on patient outcomes, Steward Health Care System evaluated its transfusion ordering practices. As a multi-facility healthcare system, Steward utilizes CPOE for all inpatient orders. There is one LIS database with multiple sites and one OM database with multiple facilities. All blood product orders were evaluated and the implementation process was prioritized for restrictive ordering practices. The restrictions placed on the OM orders were accomplished using rules and override functionality. The results are exciting! Attend this webinar and learn about it!

Learn more at

February 23, 2015, 12:34 pm

Epic-Cerner competition heats up

Stiffer competition between key vendors is leaving an increasing number of healthcare providers on the fence about which EHR system to buy, according to a new report form research firm KLAS.

In the KLAS acute care EMR purchasing plans report released today, researchers found that even though providers have fewer choices due to market contraction, they are less likely to have made up their minds about which system to buy when evaluating future purchases.

Read more.

February 20, 2015, 10:31 am

SQL Tip —The Data Request Number

Thomas Harlan, Technical Team Lead – Data Repository at Iatric Systems

As we’ve discussed before in webinars, white papers and in our SQL training classes, we recommend that all DR-based reporting and extracting be driven by stored procedures. Those stored procedures be used or consumed by either SQL Server Reporting Services reports, or SQL Server Integration Services packages, or Crystal Reports.

This splits the work into two focused areas – data retrieval and then data presentation – and lets you use each “tool” in an optimized way — which is good.

But unlike a classic NPR, your work is now split into two different sets of code, using two (or more) sets of tools, and physically stored in at least three places! And that can get confusing.

One excellent solution to manage this new environment is to implement a Data Request Number (DRN) and some structure around the process of building and deploying reports and extracts.

In the Data Request Number approach, every single data request you receive is given a unique number. This number is tracked, along with key data about who made the request in a centralized way. (For some of our customers, that is a custom web app they built, or an Access database, or an Excel spreadsheet… an example layout of the tracking tool – in Excel – is attached to this tip).

Note that every request is tracked, from every system, even if we don’t build a report or extract in response to the request. And the Data Request Number is just an identifier to let us identify things were created in response to a request – it is not necessarily structured in such a way as to identify a specific module or application – though you could do so.

The DRN Workflow

In the specific case of a data request that is met by building a stored procedure and then an SSIS extract and a matching SSRS report, we would get something like:

    • Data Request Number assigned is: M0241 (in this implementation, “M” stands for a MEDITECH report, “K” for Kronos reports, etc.)
    • The request is for a BAR-based text-file extract of UB-04 data to be submitted to the state.
    • The request includes an error report, showing issues with the data that should be corrected before the final file is created and sent to the state.
    • We create one Stored Procedure to get the data from the DR and it gets the DRN embedded in the stored procedure name like so:
    • And the stored procedure code you’re keeping in an offline copy of the database object has exactly the same name, with a .sql added:
    • Then we use that stored procedure to drive an SSRS report, where the report has multiple sections, pulling out records that meet specific error criteria. We can embed the error criteria either in the sp (adding an Error Flags field) or in the report. The key idea here, however, is that the report .RDL name also includes the DRN:
    • When you set the description property of that report, you also embed the DRN, so that it flows over into the report title the end-user sees in Report Manager or Sharepoint:
     M0241-State UB4 Error Listing
    • Finally, when you create the SQL Server Integration Services package to automate the creation of the formatted text-file, the .dtsx file also embeds the number:

We can now track all of the parts of the response to the request just by the DRN. This makes maintenance vastly easier for the programmer; gives the end-user an easy way to refer to a specific report (“I need a change to the M0241 report”); and lets you positively identify each request and what happened to it in response.

Ah, but wait!, you say. What about database objects that are generic? What if we create a VIEW in the database, for example, to ease reporting? Should they have DRN’s? And we say… no, they do not. They have names like:




With the exception of a non-generic supporting object. Say you need a SQL function which is specific to one data request, then you might have something like:


A real-life example of a request-specific function would be a multiple-file/multiple-stored procedure extract set where state-specific CPT Codes needed to be suppressed in the files sent to a specific vendor. Then you could properly build a DRN-number function because it is intimately linked to that request.

Organization of Code

We noted above that you’re keeping an off-line copy of each database object, (because you are, aren’t you?) for the day that something happens to the database and you have to recreate a single object (stored procedure, custom index, custom table, function, view, etc.) without a database restore.

This happens. It’s painful if you haven’t taken some care beforehand…

What we suggest is that you build, in a network share visible to your report developers and DBA’s, a structure like:


And everything that you put into the database you do via a SQL script, which you save into the offline folder first, then run to create (or ALTER, later) the object(s).

When you need to change an object, you change the offline .sql script first, then run it to change the object in the database. Work diligently to keep these two structures in sync! Someday it will save your… well, you will be happy you have it.

Extracts are a bit more complicated, because SSIS wants to create its own folder structure, and that tends to get deep — so deep, in fact, that SSIS can create a folder path you can’t access! Because of that, you want to shorten the path as much as possible.


The \Extract folder contains both the .sln, .dtproj and .dtsx files all in one bucket. The \SQL folder, in this case, contains all of the extract’s supporting code. Conceptually, this takes us away from the structure above, where we have more generic folders, but is much easier to manage.

RD and NPR

Nothing prevents you from using the same tracking system for new NPR(s) and RD reports, as you can set their internal name and title. You won’t be storing them in the offline storage area, however, unless you have some scripted process to dump the object versions of those report formats out to disk on a schedule.


If you’re just starting with the DR, that’s a great time to implement an organizational system like this.

If you’re migrating to MT6, that’s a great time to implement an organizational system like this.

If you have disorganized folders full of a mass of code, it’s… well, you get the idea!


Visit our report library at

You can find additional Report Writing Tips on our website at, as well as information about our on-site Report Writer Training and Report Writing Services.

To subscribe for email notifications for new Report Writing classes, please follow this link:

For more information, please contact Karen Roemer at 978.805.3142 or email

This article originally appeared in the February 2015 issue of Iatric Systems Updates! newsletter.

February 20, 2015, 10:27 am

NPR Tip: Every Module Can Have Room and Bed Index (MAGIC or Client/Server)

Joe Cocuzzo, Senior Vice President – Report Writing Services

ALSO:– Physical vs Logic “Nexting”

It is quite common to write reports for current inpatients, and a logical assumption by many NPR report writers is that such reports are best built in ADM, even when the data required is in some other application.  A very typical approach is to build a “main report” in ADM and then use (shudder) fragments or programming in a macro to get the data from OE, PHA, LAB, NUR, etc.

A better technique is to write the report in the DPM with the data, and take advantage of the fact that most clinical modules keep a prefix or all prefixes “open to” ADM.

In MAGIC, EDM, OE, PHA, LAB, NUR, and SCH keep the * prefix open to the ADM data file, (ABS, BAR, RXM, and RADRW do not).

In C/S, EDM, OE, PHA,LAB, NUR, and SCH keep all prefixes open to ADM data, dictionaries, and programs, and it is easy to open ADM from any C/S report by calling:“”,”ADM.XYZ”) in a “start macro”.

This month, we will show how to effectively “give” EDM, OE, PHA, LAB, NUR, SCH a room and bed index.  Our example will be a Pharmacy report for find all current inpatients on a particular medication.  We will use the ADM room bed index to make a list of all current inpatients in slash, and use that list in a selection for speedy access to just those patients for our report.

The first step is to pick an index for your PHA.RX report that contains ADM.PAT.urn as far to the left in the subscripts as possible, ideally as the first subscript  In EDM, OE, PHA, LAB, NUR and SCH this field is called “patient” (ABS and BAR are odd ducks with @adm.urn and @int.number just because).

In MAGIC, you have these indexes to choose from:

NPR Tip Image

In Client/Server the indexes are identical, you just don’t have to deal with the “customer name/programmer name” duality, as the C/S development team lacked a department of redundancy department.

NPR Tip Image
So our PHA report looks like this:

NPR Tip Image

The selections on the report are setup like this:

NPR Tip Image

Three points about the selections:
Selection #1
We are going to load a list of admission urns from the ADM room bed index in a “start” macro, the LI will use that list against the index file to efficiently get to all the medications of each current inpatient.

Selection #2
The index file we picked includes “status” (order status) as its second subscript.  We can restrict the report to “AC” (active) orders to make it even more efficient by hardcoding that selection as #2

It is bad practice to write a PHA report looking for particular drug mnemonics.  Nobody is going to check every formulary load to see if some new variations on a drug have appeared.  Checking the med’ for “INSULIN” with a “CO (Contains) makes it less likely that new forms of that medication will be missed.

Now we need to use the ADM room and bed index to get our list of current inpatients (and outpatients in a bed if you use that MEDITECH feature).

The room and bed index looks like this:

@room.bed.index[facility,room.bed] = urn

To use it from a Pharmacy report we need to add the DPM so the translator can find it:[ADM.PAT.facility,,ADM.PAT.bed]

Since we want to loop through the whole thing, we can use “physical next (>) rather than nesting three DO loops with “logical next” (+ or @Next).   It just amounts to a bit less typing:

Remember that (for MAGIC), only the * prefix is open to ADM in the PHA (and OE, NUR, and EDM applications).   This means you have a problem using any field where the data definition expects to use a different prefix, such as :.

The way to tell which prefix will be used is either, stick the field or segment in a test macro and watch the translation or look at the data definition for ADM.PAT.   If you look at the data definition you will see that data fields use the * prefix, but index segments translate with : instead.

NPR Tip Image

Fortunately, there is a “@Chg.prefix” translator macro you can include in your code to force the translator to use a substitute a different prefix for the one defined in the data definition:

The syntax is:
@Chg.prefix(DPM,regular prefix,prefix to use instead)
So if we do @Chg.prefix(ADM.PAT,:,*) the translator will use * instead of : for anything with a : in the data definition.  Instead of :AARB the translator will do *AARB so your code will work.

PS – using one prefix for indexes and a different prefixes for data increases the chance that data fetched from the file will be in a memory based buffer and a report will run faster, with fewer trips to the disk for more data.  This is the reason MEDITECH typically uses a different prefix for data than indexes, and opens multiple (two or more) prefixes to the application data file.

NPR Tip Image

After the start macro runs, there is a list in /PAT of all the patients currently in beds:

NPR Tip Image

This list in /PAT behaves like your own RBI index of patients for the report in PHA.

In C/S you do not need to use the @Chg.prefix, because the ADM prefixes are open in PHA exactly as the translator expects.

NPR Tip Image

Here is output from a MAGIC test system:

NPR Tip Image
Here is output from a C/S (actually 6.0) system:

NPR Tip Image

This sample PHA report in both C/S and MAGIC format: %PHA.RX.zcus.update.pha.rbi has been posted in our report library.

Visit our report library at

You can find additional Report Writing Tips on our website at, as well as information about our on-site Report Writer Training and Report Writing Services.

To subscribe for email notifications for new Report Writing classes, please follow this link:

For more information, please contact Karen Roemer at 978.805.3142 or email

This article originally appeared in the February 2015 issue of Iatric Systems Updates! newsletter.

February 19, 2015, 12:42 pm

MEDITECH Customer Avera Health Leads the Way for Stage 2 Meaningful Use

A MEDITECH customer for over 20 years, Avera Health System (Sioux Falls, SD) has long been a pioneer of quality, innovative healthcare services. And they have the accolades to prove it, including Stage 6 and Most Wired.

Now, Avera can add another feather to its cap, this time for Stage 2 Meaningful Use attestation.

Under the Eligible Hospitals category, all 24 Avera hospitals that attested for Meaningful Use Stage 2 have passed, which means all Avera hospitals in their current stage of Meaningful Use passed during their 90-day attestation.


February 18, 2015, 12:37 pm

MEDITECH: Providing Care Across Integrated Delivery Networks

Philip Barker, VP of Information Management at Fraser Health explains how MEDITECH helps Fraser coordinate patient information across their many locations and care settings.


February 18, 2015, 11:39 am

MEDITECH: Humber River Hospital Expands its Integration with MEDITECH’s Oncology Management

Humber River Hospital (Toronto, Ontario) is taking healthcare integration and cancer treatment to a whole new level, as the first adopter of MEDITECH’s Oncology Management solution with the 6.x EHR platform.

Hospital News recently reported that Humber River is using the software throughout its Outpatient Oncology Treatment Clinic, with impressive results so far.

“This system transformed the Oncology Clinic into a fully digital unit, taking Humber River one step closer to becoming North America’s first fully digital hospital,” says Oncology Manager Jane Sanders, in the publication. “It also supports our mission to put patients at the centre of their care while focusing on improving quality of care and patient safety.”