After a romantic dinner and night in the city, it was now or never.  The proposal was next and went something like this: ”EDM 6.X, like MAGIC, also needs to have tracker treatment and assessment indicators.”  Probably not the proposal story you had in mind, but most people have a proposal story – some have several.   As our site has progressed from EDM MAGIC to 6.X, we have a few.  Some of them are GAPS (gaps in functionality in 6.X from MAGIC or Client/Server) and some of them are new proposals.  I’ll share a few with you in this blog series. 

The goal is to have other 6.X sites and future sites review them and add their sites to them, an effort to collectively influence the priorities that proposals become a marriage and are applied in EDM 6.X.

Let’s start with 6.0 Proposal # 17073 – EDM Treatment Indicators

In MAGIC, our site was using treatment indicators in a variety of ways.  Our emergency department providers placed a nursing intervention order in the system, which was linked to a treatment that populated the Triage/Doc list (in 6.0 this is called the Worklist).  The order also triggered a customer defined indicator (we set RN and some others) and then disappeared once the item was documented.  In MAGIC, a dictionary in EDM established the link, and a few other dictionaries allowed the use of colors, text and placement of the indicator.

MAGIC Tracker

MAGIC Triage/Documentation Routine

In 6.0, there is a dictionary called the indicator scheme that is not as directly tied to EDM treatments as the dictionary was in MAGIC.  There are some workarounds, but  these workarounds may not work for your site, depending on your process and modules.

If you work at a current or future 6.0 site that may want treatment indicators, please look into requesting Proposal 17073.  If you’re not 6.0 but want to comment about indicators, please do so below.  If you’re interested in the treatment indicator workaround, please comment and include your email address.

 Stay tuned for The Second Proposal!

Related Posts

• November 25, 2009 -- It’s a MAD, MAD, MAD, MAD World – Part I (6)
• November 9, 2009 -- FOCUS: When/Where (1)
• October 8, 2009 -- First Impressions from a MAGIC Perspective (3)
• April 21, 2010 -- FOCUS: Now or Never? (1)
• January 21, 2010 -- The Perfect “Perfect Storm”? (0)

MEDITECH’s 6.x role based technology appears intended to simplify the clinical user’s workflow.  As a customer, you can define the menu options up to the point a user selects a patient. After patient selection, MEDITECH decided the menu and the workflow choices.  Keeping things consistent and simple seem to be key to the new workflow design.

Users may notice that in any care area, the right hand menu of the FOCUS 6.x system is the same for all users and all patients.  Rather than have menu items appear and disappear based on access, menu items are enabled and disabled based on access.

Click to enlarge.

Up to this point, a user can hop between different patients and different applications, though MEDITECH allows customers to define the maximum number of patient charts that can be open at one time on an individual client using parameters.  Beyond this point, the rules of the MEDITECH screens become a little more application specific and structured, and it appears that each area of the application is evaluated when designing the screen content.

Parent Process
The first point of entry of the clinical application is generally started as a parent process.  The parent process allows the user to maintain the open parent window while performing specific care area duties on a patient.  The user can refer to the parent window for additional information or for additional patients without needing to leave the current detailed process.  The PCS Status Board and EDM Tracker are examples of parent processes.

Detail screens can be launched from the parent process, and user access to the parent while in-process is allowed.  These secondary detail screens can be launched in non-modal or modal fashion.

Non-Modal Child Process
The non-modal child process allows user interaction in the parent process while the non-modal child is running.  Examples of non-modal child processes are the PCS Worklist and the Plan of Care Entry screen.  While the non-modal child is active for a given patient, the caregiver can return to the parent and the PCS Status Board as well as open additional charts.

Click to enlarge.

Modal Child Process
The modal child process is generally a sub-screen that displays pertinent detail about a single item on the main parent screen.  In the modal-child process, access to the main parent is allowed in view-only.  In Windows fashion, the modal child can be dragged to the side for data review on the parent, but further activity on the parent window is disabled until the user exits the modal child.

(Notice the menu buttons are disabled.  They are re-enabled when the modal child process closes.)

Click to enlarge.

Stacked Screen
There is a fourth screen choice, known to MEDITECH as the stacked screen. Unlike the Status Board to Worklist parent/child relationship noted above, the stacked screen takes over the main body of the screen in view. In these instances, the previous screen is not visible until the user exits the stacked screen.

The placement of the stacked screen in MEDITECH’s 6.x environment seems to be necessitated by the application. Stacked screen display when it is logical to do so.

The Plan of Care screen shown below is an example of a stacked screen. The detail of a single item on the plan of care displays fully. There is no clinical reason to maintain the previous while viewing this detail, and it is therefore presented as a stacked screen.

Click to enlarge.

By the involving the stacked screen, MEDITECH has kept the number of jobs listed in the Windows task manager to a manageable few.

It appears that MEDITECH put a lot of thought into the design of the 6.x Advanced Technology screens. I’m sure that MEDITECH believes that their design of screen and workflow will suit all customer’s needs. I wonder if you agree?

Related Posts

• No Related Post

The ForUpdate mutex defines a mutex record only when the data is updated, thus limiting the amount of time that the record is locked. Examples of ForUpdate mutexes are OM Clinical Data entry, OM Order entry, and PCS Assessment edits. The key difference with a ForUpdate mutex is that the cached data value at import time (the time the user initiated the update) is compared with the permanent data value on the server prior to updating. If the data value on the server is newer than the value that was imported by the user prior to the edit, the user cannot update the record.

For example, user one imports a PCS Assessment record and proceeds to edit. User two imports the same PCS Assessment record and proceeds to edit and file. User one then attempts to file the edit and gets a warning that data on the server is newer than the data in the local cache, and therefore the edited values cannot be filed. In this case, the user must throw away the edit and begin again.

There are also instances when no mutex is obtained. If the application determines that the data being filed is not in jeopardy of being interrupted, then a mutex is not assigned at all. As an example, new assessment documentations do not require a mutex because the data is fresh and free from editing that would cause data integrity issues.

So besides changing the name to a more techy sounding word, MEDITECH has made some significant logic changes to their locking mechanism in the new technology. While these algorithms may lead to less frequent locks in general, who wants to be in IS when that call comes in from a user who has been documenting away and is now told she must discard her changes?

Previous post:  The Mutex

Related Posts

• March 2, 2010 -- The Mutex (1)
• April 13, 2010 -- Scripting the “Chain Gang” (0)
• November 25, 2009 -- It’s a MAD, MAD, MAD, MAD World – Part I (6)
• November 9, 2009 -- FOCUS: When/Where (1)
• October 20, 2009 -- When Wizards are King (0)

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?

Related Posts

• January 29, 2010 -- Finding your way around 6.x (0)
• January 13, 2010 -- Report Designer Part 2, A Detailed Tour (1)
• December 4, 2009 -- All Show and No Go (1)
• November 17, 2009 -- Please Pass the Ketchup (2)
• November 9, 2009 -- FOCUS: When/Where (1)

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.

Related Posts

• March 25, 2010 -- Will MEDITECH Expose Programming Code in 6.x? (1)
• March 17, 2010 -- The ForUpdate Mutex (1)
• January 29, 2010 -- Finding your way around 6.x (0)
• November 25, 2009 -- It’s a MAD, MAD, MAD, MAD World – Part I (6)
• February 17, 2010 -- It’s a MAD, MAD, MAD, MAD World – Part III (2)