Message from
Senior Management

The Double Feature of Focus
 

Joel Berman
President
 

Post-MUSE
Webcasts

Iatric iPhone
Applications

Joel Berman, President

The latest version of MEDITECH's HIS software, known as FOCUS or Client Server (C/S) 6.0, is the talk of the community.  Focus represents the biggest change in MEDITECH's technology in the past 25 years.  When C/S was introduced in the 1990s, everyone thought it was a whole new technology.  It, however, represented more of a change in where the software executed (client vs server) rather than a new technology.  C/S was built on the same proven MAGIC database/ programming language that had been around since MAGIC was introduced in the early 1980s.  Consequently, most MAGIC customers wondered why bother.  Very few MAGIC customers converted and there were even a few C/S to MAGIC conversions.  However new customers purchased and installed C/S successfully.  The reaction to Focus has been radically different.  Many longtime customers are lining up to upgrade.  Why?

From talking to most of the early converts, the main reason for interest in Focus is that it has a whole new user interface (UI). Rather than lots of menus, keystrokes and drilling down to get at data (like in PCI) most screens consist of a list of things the user needs to work on, the information they need to see, a quick way to access more information and a way to work with the items on the screen. The list might consist of all the patients on a doctor's rounds or a list of patient accounts for a biller to work on. The screens are created based on the user's role within the hospital. MEDITECH also makes use of Windows and a mouse rather than keystrokes to make screens easier to learn and more usable for physicians. That's the good news and the feature most people see and want.

The other part of FOCUS is the new database technology. FOCUS is built on a new database technology and design. While there are some new features like an audit trail for every change made to every field in the system, the new database comes at a very high cost. The cost is that every report, every attribute, every rule, and every interface you've created for your existing system has to be rewritten. This means throwing out years of work whether you are an existing MAGIC or C/S customer. It also means that conversions will be much harder than if they had not changed the underlying database technology. MEDITECH has over 2000 customers. If they converted one a week (which I doubt they could come close to) it would still take over 40 years to convert everyone. Many of you have talked to me and asked, why didn't MEDITECH just create a new UI on top of the existing database? I agree. If all you had to do was to load a new client but could leave the database and database technology alone, then this would be a valuable and relatively easy upgrade. Unfortunately that is not the path upon which MEDITECH focused (sorry, I couldn't resist).

Obviously the story of FOCUS will be written over the next few years. Whether I agree with them or not, we are committed to continuing to the deliver of software products, interfaces and report writing to FOCUS clients. At the recent International MUSE conference in Vancouver, MEDITECH publicly stated that they are committed to supporting and developing MAGIC for many years to come. Are they trying to tell us something with that commitment? What do you and your hospital think about FOCUS?

We are hosting Post-International MUSE 2009 Webcasts featuring solutions to your most critical issues. Let Iatric Systems help you FOCUS on the Future. 

Knowledge – The first step to building an effective strategy is to gain a profound understanding of current and future operating environments. Over the past couple of years we have been working with our customers, 6.x beta sites and industry leaders to increase our awareness and understanding of the 6.x platform and MEDITECH’s roll-out strategy.

Communication – The 6.x/FOCUS platform continues to evolve as applications are  converted by MEDITECH. We remain committed to fostering information sharing for the benefit of all MEDITECH users. We were the first vendor to present a technical education seminar on FOCUS technologies through MUSE. We were also the first 3rd party vendor to sponsor an independent educational seminar that brought Chief Information Officers at hospitals using MEDITECH together to share migration strategies.

Development – Equipped with acquired knowledge and understanding, a team of developers and managers have been working full-time to address the key issues of data access, scripting and application integration (launching/linking). Early success has been achieved in all three of these areas and will continue throughout the year as the Focus Integration Team works to integrate existing Client/Server applications with this new platform.

Current offerings in the 6.x/FOCUS Platform
• Scriptlink+
• 6.x Client/Server interfaces
• 6.x FOCUS interfaces
• 6.x Client/Server products
• 6.x Client/Server NPR Report Writing
• 6.x FOCUS Report Writing
• Exposure of FOCUS data via the Client/Server report writer (scheduled release in 2009)
• Integration strategy consulting for the 6.x environment
• Interface/Integration Engine and related services
• Document imaging conversions to MEDITECH Scanning and Archiving

FOCUS on the Future
The migration to 6.x/FOCUS will be a multi-year and multi-stage journey for most MEDITECH users, especially early adopters. We are aggressively enhancing and migrating existing products, interfaces and services to meet the needs of the MEDITECH community. As MEDITECH applications are enhanced in the new 6.x/FOCUS platform, some Iatric Systems' product features may not maintain the same utility as they have in previous platforms and therefore may not be converted. Our commitment is to listen to you and the MEDITECH market in order to meet current and emerging needs. We remain focused on helping you leverage your MEDITECH investment. 

If you own an iPhone or iPod touch, then we have something for you!!! We are proud to announce the launch of two new applications to make your life easier.

MEDITECH-L list
If you currently subscribe to the MEDITECH-L list, then you may view it while away from the office on your iPhone/iPod touch. You may download the free 'MEDITECH-L Search' from the iTunes App Store as you would any other iPhone application.  This program will allow you to perform searches directly and filter the list based on a date range. 

iAlert
If you are an iAlert customer then you may monitor your iAlert notifications from your iPhone/iPod touch.  You also have the ability to modify your iAlert notification parameters via your Iatric iWeb account.  You may download the iAlert Mobile Client via the iTunes App Store. 

We will host two training sessions for all current iAlert customers on
July 16, 2009 at 10:30 am EST and July 22, 2009 at 2:00 pm EST.  Please email Pamela.Brock@iatric.com if you would like to register or for more information.

Kay Jackson, Marketing Manager - Financial

MAGIC 101 - Queuing, Queued Strings  (MAGIC or Client Server)

One of the differences between $T and NPR applications is that NPR data (on both the MAGIC and C/S Platforms) is stored in "packed pieces" or "queued strings", meaning that more than one field is stored in a given node.  In $T applications (RAD, PCI, system tables) most data is stored in one field per node. Here is the device table, for example:

Compare that with an NPR (MAGIC) ADM.PAT record:

C/S is very similar, except that the prefix is $(A) rather than just *.  :

Storing data in this fashion saves space and can allow for quicker data access.   You can only store a maximum of 255 characters and separators in the queued string.  This kind of string is subject to the same MAGIC 255 maximum length limit as a line of source code, or a variable name and value pair.

In fact, an NPR report stores the "top node" of the detail segment in X and uses the pipe operator to extract the data fields from X rather than using the actual data node for all the fields in this top node.  This technique is called "buffering". 

Here is an ADM.PAT report example:

The object code shows how the Report translator uses "buffering" to put the fields from the *AA[aa] (top node) in X, then prints fields from that segment:

How can we use this technique in our own reports?

Often you will use a fragment to get data from another application, and will need to return several values to the main report.  Typically, you will store the data in /R.FRAG.VAL and add some invented subscripts for your different fields.  For example, in a lab report that returns the most recent Glucose result, you would store:

@collection.date^/R.FRAG.VAL["DATE"],
@collection.time^/R.FRAG.VAL["TIME"],
@result^/R.FRAG.VAL["RES"],
@abnormal.flag^/R.FRAG.VAL["FLAG"]

Our computed fields would print the data from the main report as follows:

xx.result
DAT=FREE
LEN=10
VAL=/R.FRAG.VAL["RES"]

An alternative approach would be to pack or queue the data into /R.FRAG.VAL as follows:

Here using the Q command
Q(@collection.date,@collection.time,@result,@abnormal.flag)^/R.FRAG.VAL

An alternative syntax for the Q command using curly braces
{ @ collection.date,@collection.time,@result,@abnormal.flag}^/R.FRAG.VAL

Using a queued string makes our code shorter, and we can sneak it into a footnote in the fragment.  Creating separate nodes in /R.FRAG.VAL would require putting the code in a macro in the fragment or placing it in an LC or ECB.

You might think that the curly brace alternative syntax is just a MEDITECH obscurity, but it actually makes a certain sense, because you can reverse the syntax to unpack the fields and place each one in a variable like so:

/R.FRAG.VAL^{DATE,TIME,RESULT,FLAG}

This does the same thing as:

/R.FRAG.VAL|0^DATE,
/R.FRAG.VAL|1^TIME,
/R.FRAG.VAL|2^RESULT,
/R.FRAG.VAL|3^FLAG

Another way to put data into a queued string is to assign it to a particular "piece" using the pipe operator.  For example, lets say we were keeping a running total of ER registrations by hour of the day.  Rather than have a structure like this  /TOT[HR] = total for that hour, we could keep everything in /TOT where the piece represents the hour:

@service.time$2+0^h
1+/TOT|h^/TOT|h

As soon as you assign something to a piece, all the prior pieces are created with nil stored:
If we do 1^/TOT|23 The structure looks like this:

PS, the arrows you see in the structure are markers that the system stores to indicate the length of the corresponding piece.  This /TOT string has 22 ASCII zero's stored, then an ASCII 1, then the data "1".  Usually the pieces are so short that the G command shows just the caret, as they are unprintable ASCII.

If you store a long enough piece, you start to see printable characters used as the delimiter, for example if we put a string of 100 x's in piece zero of /TOT like this "x":100^/TOT|0, we see a lower case d (ASCII value = 100) before the string of "x"'s:

You can find additional NPR Tips on our website at http://www.iatric.com/information/npr-tips.asp, as well as information about our on-site NPR Report Writer Training and NPR Report Writing Services.

Sign up for our Updates! newsletter, or do so by visiting the lower section of our website's homepage.

You can unsubscribe from this newsletter using the SafeUnsubscribe link at the bottom of this email or by sending us a request at info@iatric.com.

If you received this newsletter via email, you may give us feedback by simply replying to the email.  However, if you would like to reach someone directly, please feel free to contact one of the individuals listed below.

Joel Berman, President, Joel.Berman@iatric.com, 978-805-4101
John Danahey, VP, Sales & Marketing, John.Danahey@iatric.com, 978-805-4153

27 Great Pond Drive, Boxford, MA  01921, USA

Copyright 1996-2009 Iatric Systems, Inc.  -All Rights Reserved-