On FOCUS

by Michelle Schneider

I have really been diving into MEDITECH’s 6.0 Clinical Panels.  This is, after all, the latest MEDITECH has to offer for patient chart review and support for clinical decision making.   I find it very frustrating though, because it’s difficult to get a good flow of data evaluation.  In MEDITECH’s demonstrations, the data is all perfectly placed in these narrow columns so that the user gets a wonderful vibe of an easy, relaxed chart review.  However, as soon as reality strikes, users realize that all responses are not less than 15 characters.  A user is notified of a longer response with an ellipsis after a truncated entry.  In order to see the  longer response, he must click once to open an additional screen, move the mouse to the bottom right of the screen, click close and then continue the chart review.  In the assessment below, which certainly represents a very limited assessment, the user cannot easily glean the patient’s status.  There are so many entries with the ellipsis after them that the user is forced to click on each to see the response.

This results in a very clunky workflow.  If you count the keystrokes required to view the first (and shortest) entry in this example, the user would have to use 10 keystrokes.  This may irritate users and in some cases, the user may think the beginning of the entry is intuitive and assume the remainder of the response in order to save time. However, this represents bad practice and could result in compromised patient safety.  For instance, the “Gastrointestinal” entry has two responses, which are both truncated with an ellipsis.  They are “Bowel Soun…” and “Abdomen D…”  Upon clicking on the row, the user sees that the entry is “Bowel Sounds Hypoactive” and “Abdomen Distended.”  The user can then sweep the mouse to the bottom right of the screen, click close and return to the assessment.  To see all of the entries on this screen, the user will have to click 40 times.  That is not a typo.  FORTY clicks!  Wow.  There is no apparent method to widen the columns and no apparent method to use that blue space to the right of my last column.  It’s just sitting there, teasing me.  Sure would be a good place for the rest of my results.  Hmmmmm.

How do you think your clinicians will react to this method of chart review?  Can this, will this meet their needs?

by Joe Cocuzzo

Some aspects of the new Report Designer are actually nicer than those of the NPR Report Writer.    Field selection and field placement on the picture is quicker and easier.  Of course, if you have the NPR RW keystrokes and NPR RW functionality burned into your neural pathways, you might think that you are doomed, but you may have felt that way when you lost 10 function keys going from your Esprit 105c to a PC but I bet you cannot describe the difference between the fat, skinny, and double arrows now!

The Lookup on the fields page is much more convenient than that in the NPR Report Writer fields section on the picture page:

Click to enlarge.

Click to enlarge.

To put the run time selection values on the report, you do not have to build a special computed field. The Report Designer builds them for you and makes them available if you select the “Selects” button at the bottom of the Fields page:

Click to enlarge.

At the bottom of the Fields page is a Fields Links button.

This brings up a 10th page where you can map a field from the detail record/segment to fields from an additional record, using an index if necessary.

For a simple child record/segment, the Report Designer seems to be able to create the link for you automatically:

Click to enlarge.

Stay tuned for our next post, “Regions and Layout.”

Did you miss an earlier part of this series?
Part 1: A first look
Part 2: A Detailed Tour
Part 3: Why can’t I delete or edit the field that is highlighted????!!!!

by Ed Bishop

MEDITECH has revisited locking in their Advanced Technology platform, and has replaced the lock with mutual exclusion (often abbreviated to mutex) algorithms. MEDITECH mainly uses two mutex definitions, the ForUI mutex and the ForUpdate mutex.

The ForUI mutex defines a mutex record surrounding the work in progress, locking the entire user interface. The mutex is defined with a time period of ownership. While the user is processing the locked record, no other user can gain access to that record.

If the mutex ownership period expired and hasn’t been renewed by the application holding it, the mutex may be obtained by a different user. They added this feature to aid in the resolution of lost locks.

Additionally, if a single user has acquired a mutex and then tries to do that same process again while the mutex is retained, the process may allow that single user to self-preempt the mutex and gain control of the process.

If a mutex has been preempted from the first user (even if they’ve preempted themselves), that user receives the following message upon filing:

The ForUI mutex is generally reserved for dictionary edits, but can also be found in limited areas of patient data processing, including the Amend Note routine, Length of Stay edit routine in the PCS Patient Plan of Care routine or the Document Med screen of the PCS eMAR.

Next time I’ll take a look at the ForUpdate mutex.

by Janet Clarke

When you consider the impact that a 6.x migration would have on your end-users, bear in mind that a significant amount of time will need to be arranged for the re-education of the clinicians who will be using the PCS (NUR) module. The documentation routines in 6.x will feel somewhat familiar to current Client/Server (C/S) users, but very different to those currently in the MAGIC community.

First off, there is a change in the lingo. For MAGIC users who are unaware, the NUR Module is called Patient Care System (PCS) in C/S and 6.x.

In C/S and 6.x, MEDITECH’s Status Board is required to access a nurse’s patient list. This functionality has been available for some time in MAGIC but is not required.

The 6.x Status Board has a different look and feel than its MAGIC and C/S predecessors. The new Status Board has two main sections. The top section displays a list of an individual clinician’s patients with a spreadsheet array. The patient assignment editing routines are available on buttons at the bottom of this screen. Access to alternate lists is set up in the PCS Access/User Preference dictionary.

The patient list may be set up with pinned columns and a horizontal scroll for data that does not fit within the initial display. The functionality is somewhat improved over earlier versions as users may use click functionality within this section to view more information such as interventions or medications that are due, or new orders or lab results.

Click to enlarge

The second section of the Status Board displays below the first and is the source for further patient detail. This is a curious design because it requires the user to look in two different places on the same screen to view patient data. If the highlighted patient happens to be at the top of a lengthy patient list that requires a vertical scroll, then the user may not be able to visualize both sources of patient data on the screen at the same time!

Click to enlarge.

This two tier Status Tier design could contribute to the user not having access to complete patient data at one glance – with ramifications in terms of clinical decision making.

More 6.x Status Board scrutiny with the next post …

by Mike Devoe

In a prior posting, I reminisced about my early days as a script programmer when I thought scripting would eventually become obsolete.  My thinking was scripting would remain viable as long as we were working with terminal emulation where we could easily watch text being written to the screen.

Over the years, terminal emulation didn’t go away.  Instead, it became more complex as MEDITECH tried to jam in new “Windowish” features such as grids, buttons, combo boxes and drop-down menus.  As MEDITECH tried to make terminal emulation look more like Windows, we ended up with a lot of screens that both looked and behaved differently.  I’m sure having so many different styles of screens was irritating to the users.  To a programmer developing a scripting tool, it was downright maddening.

I doubt MEDITECH ever expected anyone to look at their software as I do.  As described in my previous post, I watch their workstation software ask the operating system to do stuff such as draw text on the screen.    As MEDITECH began hanging “Windowish” features on their terminal emulation, it started looking like a real mess when you looked at it from the operating system’s point of view.  I’ve watched their applications use up to eight different ways to write text, two of which involved writing entire screens one character at a time.  I’ve seen a half a dozen different ways to draw a button.   On some screens, buttons are real Windows buttons while on other screens they’ve drawn a picture of a button and just sense if the user clicked on the screen region where the button had been drawn.  These inconsistencies touched everything, which made tracking their screens a real nightmare for scripting tool developers.

When FOCUS (and Client/Server 5.6) came along, the new more consistent look and feel of the application was not only pleasing to users but it greatly simplified scripting.  FOCUS now behaves consistently under the hood, similar to neat and orderly terminal emulation.  From the operating system’s point of view, everything is clean, efficient and well-mannered.  When they write text, they write it one way.  When they draw a button, they use a single methodology.  Despite the fact that FOCUS and C/S are not terminal emulators; I’m pleased they look so much like it from my point of view.