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)

What many people forget, including other vendors I’ve spoken with, is that 6.0 is mainly C/S and only a few modules (EMR, PCS, MIS, EDM and others) are based on the new Advanced Technology. This means that if you are a MAGIC site, you have to convert most of your system to C/S and some to FOCUS. When 6.1 is released, ABS, ADM and BAR (among other modules) will be converted to FOCUS. So that means if you just converted your BAR system from MAGIC to C/S, you now have to convert it from C/S to FOCUS. When 6.2 is released, you get to convert LAB from C/S to FOCUS. I know you’re also wondering: what happens to the data each time you convert? I keep asking that question but no one seems to know the answer. Good question to ask MEDITECH. Going through a series of conversions for the next few years wouldn’t be high on my list of things to do if I were in your shoes.

So what’s the best strategy? Each of you needs to figure out what’s best for your facility. Maybe the best idea is to get in line for 6.2. At that point you would have a product that’s mostly FOCUS and you’d only have to convert most modules once. Can you afford to do this? Others might ask, “Can you afford not to do this?”

Related Posts

• November 25, 2009 -- It’s a MAD, MAD, MAD, MAD World – Part I (6)
• May 24, 2010 -- The First Proposal (0)
• January 29, 2010 -- Finding your way around 6.x (0)
• January 21, 2010 -- The Perfect “Perfect Storm”? (0)
• January 6, 2010 -- We want MEDITECH to Succeed (0)

For those of us who have worked in FOCUS, we know MEDITECH will fire up and close multiple instances of the FOCUS client as we navigate through the system.  The sign-on process and main menu navigation is one instance of the FOCUS client; if you launch into an application, MEDITECH starts a second instance of the FOCUS client.  This reminds me of an old technique in the very early days of personal computing called “chaining.”  I’ll date myself here; Applesoft BASIC, Commodore 64 BASIC and IBM BasicA all offered a “Chain” command.  You’d chain programs together to conserve memory and give the user the impression they were running a single application.

Although MEDITECH doesn’t need to worry too much about conserving memory, they probably still want to give the user the impression of a consistent, single application.  Aside from cluttering up the taskbar, I can see how this helps them “chain” together different technologies.  For example, B/AR is still a C/S application in 6.0, so your FOCUS client launches the C/S client application and it appears to be one continuous session to the user.  I suppose savvy users can take advantage of this by signing on once and then branching all over the place with multiple child sessions.  However, I think the typical user sees this as a single application and doesn’t go branching off in multiple directions.

Keeping track of all of these sessions can be a real headache for those that develop scripting tools.   Just following the application as it chains from one instance to the next is quite a trick.  Since I don’t even want to think about branching off in multiple directions, I don’t.   The scripting tool works just like the typical user sees the MEDITECH session.  It drills in and then backs out.  Inside the scripting tool, FOCUS behaves as a single application where we’re simply stacking windows as we go in, and then removing them from the stack as we back out.  It doesn’t matter if those windows go across different applications; the scripting tool presents it to the script programmer as a single application.

This is consistent with the role of a scripting tool.  The idea is to take something inherently technical, such as following an application as it chains to multiple instances of itself, and boil it down to an idea of stacking and un-stacking windows.  Sure, we lose the ability to branch in multiple directions, but I can’t imagine why I’d want to do that in a script and I certainly don’t want to think about what that script code might look like.  I’m content to let the scripting tool work the chain gang for me and I’ll stick with writing scripts.

Related Posts

• March 19, 2010 -- We Ain’t Afraid of No Mice (0)
• March 17, 2010 -- The ForUpdate Mutex (1)
• November 25, 2009 -- It’s a MAD, MAD, MAD, MAD World – Part I (6)
• November 9, 2009 -- FOCUS: When/Where (1)
• November 4, 2009 -- Perspective on Scripting in FOCUS (1)

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

Recently, there has been a growing trend of concern expressed by some sites (particularly MAGIC sites) about the possible migration to the 6.x platform.  Some of this has been shared on the MEDITECH L-list while other concerns have come up in private conversations with various IT leaders.  I’ve spoken with many existing MEDITECH customers who are currently on the 6.x waiting list, but also many who are not.

Several of the folks who are not on the 6.x waiting list are currently going through an HIS selection process, and several have already chosen a non-MEDITECH HIS.  Considering Iatric Systems has contracted with roughly 50% of all MEDITECH sites and I’ve been with Iatric Systems for 15 years, it shouldn’t be taken lightly when I say I’ve never heard of so many sites moving to Siemens, McKesson, Cerner, Epic or Eclipsys.  Then again, there has never been a time in healthcare IT like we’re experiencing today where user adoption is paramount and every system is under the microscope of Meaningful Use.

To MEDITECH’s credit, there are also a healthy number of sites I’ve spoken with who are currently on MAGIC (or 5.x Client/Server) and have no plans to move to 6.x or any other HIS at this time.  After all, both the MAGIC and Client/Server 5.6.4 versions will be certified to meet meaningful use requirements, so (apart from an increase in user adoption via a better looking UI) there is no real healthcare mandate to make the jump to 6.x today.  There is also the cost of a new platform as well as previous IT investments to consider.  Some hospitals are in no hurry to abandon all the time and capital they’ve invested in customizing their current system to the needs of the organization.  Reports, dictionaries, menus, user access, rules, attributes, macros, custom programming and 3rd party applications have all contributed to the tailor-fitted system they have in place today.  Perhaps in these cases, the new benefits aren’t enough to outweigh the loss of investment in current technology.  Clearly, there is no one size fits all answer to this question.  What are your thoughts?  We welcome your comments on this topic.

Related Posts

• November 9, 2009 -- FOCUS: When/Where (1)
• February 17, 2010 -- It’s a MAD, MAD, MAD, MAD World – Part III (2)
• January 21, 2010 -- The Perfect “Perfect Storm”? (0)
• January 19, 2010 -- If knowledge is power, then why do I feel so powerless? (0)
• January 13, 2010 -- Report Designer Part 2, A Detailed Tour (1)