On FOCUS

by Frank Fortner

One of the things Iatric Systems’ development team has been working on for the past few years is pulling data across from the MEDITECH Advanced Database (MAD) back to a job running in NPR. Yes, I realize it “can’t be done.” If only I had a nickel for every time I’ve heard that one. Anyway, the truth is, we’ve had LIVE code doing this since the summer of 2008. For the past two years, we’ve continued to develop a robust set of tools for extracting data from the MAD and in the process have become familiar with some of its interesting nuances. Let’s take a look at what it means to “coalesce.”

To paraphrase dictionary.com, the definition of coalesce is to take multiple entities and unite them into one. What does that have to do with the MAD? Only everything, if you want 6.x to perform as well as your 5.x systems did. Coalescence is the technique that MEDITECH uses to speed up the import times for MEDITECH Advanced Technology (MAT) applications.

Let’s review the MAD structure. The MAD is an append-only object-based relational database. Each object exists in its own file on the server and Advanced Technology uses requests made through the advanced network protocol (ANP) to retrieve those files (or pieces of the files) when they need objects, records, or index data. (Quick review: objects and records used to be called DPMs and Segments). Some simple examples of Objects include RegAcct (Patient Visit data), HimRec (Patient’s Medical Record data), OmOrd (Order data), OmCategory (Order Category data) and OmProcedure (Order Procedure data). Each of these objects has its data stored in a separate file on the server.

For example, suppose we wanted to print a report to look like this:

How many objects did I have to import to display this data? Did you come up with 14? In order to display all of this data, you would have to request 14 different objects from the database. You need: 1 RegAcct to get the account#, 1 HimRec to get the patient name and unit#, 4 OmOrd for each order’s order#, service data, category mnemonic, procedure mnemonic, 4 OmCategory objects for the category’s description and 4 OmProcedure objects for the procedure’s description.

So the program would need to make 14 requests to the server through the ANP service. It bears repeating that ALL database requests go through ANP. If you’re really MEDITECH-savvy, you’ll also notice the similarity of ANP to a certain executive’s initials. Back to my point – 14 transactions with ANP is a lot of requests for a very small amount of data. Imagine you are running a report on 100 patient visits with around 50 orders each. This could bottleneck quickly without an elegant retrieval strategy.

MEDITECH wanted a way to combine these request into a groups of ANP requests, and this is where the term coalesce is used. If we could combine all 14 requests into a single request, then the import performance would increase dramatically. That would be nice, but it isn’t quite that simple. In our case, due to data dependencies, we would need a specific sequence of events. Therefore, we could import the OmOrd.Main records first, and then get a list of Categories and Procedures we need, and then import OmCategory and OmProcedure objects. So essentially, we could group about half of the requests together in one request, then group the second half into another request – still much better than individual requests.

This should give you a glimpse into the main reason for the performance issues we (and others) have observed with the new Report Designer. The translator cannot simply combine all record imports that a report needs into a few database requests. This is due to the dependencies of objects on other objects’ data in order to import them. Likewise, they cannot simply import the data one object at a time because it is much slower and causes a lot of network traffic. In some ways, the MAD shoots itself in the foot because its relational database interferes with the simple transactional nature of the MAD database. What we have then in our MAD world is a database technology that is very fast at filing data, but not so fast when retrieving data. Ironically, this is the exact opposite of how MAGIC and CSMAGIC worked. Having said that, to their credit MEDITECH has shown tremendous resiliency and creativity over the years with their database architecture, so I remain hopeful that future improvements in the database and report writer will solve some of these issues.

MAD Part I
MAD Part II

by Joe Cocuzzo

Don’t be fooled by the blue highlighting on data in a field in the Report Designer. Just because the data is highlighted, this does not mean you can do something to it (like delete or change it).

If you do not see a drop down arrow, or the X tool in dark blue, you cannot do anything to the highlighted field. Generally, to remove or change something, you have to go to the lowest level and work backward. If you picked an application, then an object, then a record, and from the record a set of fields, to change the application you need to delete the fields, then the records(s), then the object(s), before you can delete or change the application. The only hint about the restriction is that the X is greyed out at the application, object, and record level, and only enabled at the field level. Fortunately, you can delete fields from the field list without also needing to remove them from the layout.

It would be extremely helpful if MEDITECH provided help if the user hovers over or tries to click a greyed out tool. The alternative is that the user has to imagine the reason that an operation has been disabled and experiment to see if the theory is accurate.

After you have selected your application, object(s), and record(s) on the Main page, you define the general characteristics of the report on the General page. Most of the page is straightforward. It is unfortunate that they have included a whole attribute section that does nothing (so far), with no hint that it is just hanging around waiting for some future features. Also, the “Show Report Selections in Section” prompt apparently only does something when a report is scheduled; it does not automatically put the run time selection values in the report header when a report is printed directly.

Click to enlarge this image.

Sorts and selects have been split into two pages:

Click to enlarge this image.

On the fields page, the record/segment list is shown at the top and fields that you have selected from that record/segment are shown when the record is highlighted:

Stay tuned for the next article in this series, “Much More Convenient Field Selection and Entry (at least at first).”

Did you miss an earlier part of this series?
Part I: A first look
Part 2: A Detailed Tour

by Mike DeVoe

Regardless of the mysteries under the hood of the new FOCUS client, we’ll always be able to control it from a script.  In a nutshell, scripting is nothing more than reading screens and sending keystrokes.  In the MEDITECH MAGIC days of terminal emulation we could write our own emulation to send keystrokes and manage the screens ourselves.   Later, MEDITECH was kind enough to give us a “script DLL” widget so we could read their screens and send keystrokes through the workstation application.

In FOCUS, the client is not a terminal emulator and even if it were, we probably couldn’t figure it out.  MEDITECH no longer provides a scripting DLL widget so it seems we’re on our own.  As far as the scripting basics of “screens and keystrokes,” we’ve got keystrokes figured out.  If you’ve done much Windows programming, you know sending keystrokes and simulating mouse clicks are fairly straightforward tasks.  Reading screens, however, is a whole different story.  In a Windows application, by the time text hits the screen, it is no longer text.  Instead, it is a collection of pixels that represent the text.  Much like closing the barn door after the horse has run off, by the time text hits the screen, we’ve missed it.

The trick to reading text is to read it before it gets to the screen.  Windows applications don’t get to talk directly to hardware such as screens and keyboards.  Instead, when an application wants to draw text on the screen, it has to ask the Windows operating system to do the drawing.  If a scripting tool can wedge itself between the FOCUS client and the Windows operating system, we can watch FOCUS ask the OS to draw text.  If we can watch this happen, we don’t need to read the screen.  We’ll know what is on the screen as it is being written.

In fact, we can watch the FOCUS client ask Windows to do all kinds of stuff so we can know exactly what it is up to at all times.  As Fleetwood Mac suggested in their 1987 single, we can also choose to tell “sweet little lies” if it suits us.  A scripting tool might benefit from watching the FOCUS client ask Windows how big the screen is and then tamper with the answer.  If FOCUS thinks it’s always running on an 800×600 display, it will draw screens at the exact same size, which helps us write more portable and consistent scripts.

As long as MEDITECH runs on Windows we’ll always be able to control it from a script.  Instead of trying to figure out what the FOCUS client is thinking, we can just watch it interact with the outside world to know what its doing.   Short of MEDITECH abandoning the Microsoft platform, scripting is here to stay and will continue to work just fine in FOCUS.

Check out the video below to see a script running on the 6.x platform:

by Ed Bishop
With the release of the 5.6 version of their Client/Server applications, MEDITECH took the first step toward creating an integrated hybrid of Client/Server and FOCUS (or Advanced Technology) applications. The user interface in 5.6 is much more modern looking than prior versions. With its rounded corners, expansion of the color palette beyond battleship gray, and the use of buttons rather than tabs, the screens look much more like the FS (EMR, PCS) and Advanced Technology applications.

In fact, they’ve done such a good job that as an end user it’s difficult to tell whether you are in a C/S application or an Advanced Technology one. Take a look at the two screens below and notice some of the subtle differences that you can use as clues.

The biggest difference you’ll notice is that on the C/S screen (from PHA) you’ll notice rounded corners on the main body, while on the Advanced Technology screen (from PCS), the corners are square. Also look at the small “i” on the left side of the header. On the C/S screen, it’s in an octagon and there’s a light vertical line between it and the rest of the header. On the FOCUS screen, it’s in a circle and the vertical line is not there. The right side menu is usually bigger in C/S, although in FOCUS it’s variably sized based on what displays. The five buttons in the lower right section of the screen are bigger in C/S.

C/S PHA Edit Patient Data

Click to enlarge.

Click to enlarge.

As an end user, it’s nice to have a product that looks the same no matter where you are. But sometimes, as a programmer or report writer, it’s helpful to know whether you are in NPR or Advanced Technology, in case you want to know where to find data displayed on the screen. In 6.0, you just have to look a little harder to figure it out!

by Frank Fortner

Timing is an amazing thing.  In almost “perfect storm” fashion, MEDITECH hospitals are currently operating in what looks to be the most transitional time in  health care information technology history – certainly in the two decades I’ve been working in this industry.  The convergence of the push to migrate to Client/Server 6.x and HITECH’s drive to meet Meaningful Use criteria through certified systems over the next few years is a tall order to place on many hospital IT staffs, even the larger ones.  In recent days, many hospitals have been forced to rethink (or create for the first time in some cases) their 3-5 year IT strategic plan to meet the demands that the new legislation requires by 2015.  In keeping with the blog theme, just where does MEDITECH’s new platform (6.x / FOCUS / Advanced Technology) fit into all of this?

There doesn’t seem to be a single correct answer to that question as it will depend on whom you ask.  For some, this “perfect storm” is ironically quite timely and fortuitous, meaning yes, it’s a lot to bite off, but they would have been looking to upgrade from MAGIC to something else anyway, mainly in the hope of securing provider adoption.  The new Advanced Technology platform gives these hospitals a viable option that comes from their current vendor of choice.  As a colleague of mine has been known to say, “sometimes the devil you know is better than the one you don’t.”  The only challenge here may be one’s place in the queue and the bandwidth of MEDITECH to convert these systems well before 2015.

Others, even some long-time MEDITECH customers, have simply chosen a different HIS vendor, perhaps looking to capitalize on a more mature platform than 6.x, which currently lacks the basic tools for writing reports to mix data from C/S and AT applications for example.  Those will certainly come in time, but for now it highlights the freshman nature of 6.x.

Another response has been, “we’re staying put on MAGIC.”  This translates to, “yes, it may look like DOS (according to many physicians) but we’ve invested years in getting it to fit our environment.  It’s mature and robust and there are modern 3^rd party tools out there to help meet Meaningful Use criteria and allow us to gain provider adoption.”

What does your hospital’s road map to 2015 look like?  This could be the most important discussion for many of us in our IT careers, so please feel free to comment and contribute your thoughts.